On Thu, 7 Oct 2021 at 21:33, Robert Raszuk <rob...@raszuk.net> 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. >
Those other definitions don't matter, because they're not the IPv6 definitions of an interface, and IPv6 is what we're talking about here. That is the protocol you're saying you want to use. A SID by itself can have any definition you like - 20 bits, 128 bits, 1024 bits if you want. However, once you want to put a SID value into an IPv6 DA field, then the SID value is now required to comply with IPv6's definition of the DA field, and therefore the IPv6 addressing architecture in RFC4291. Same with the IPv6 definition of an interface. The IPv6 IID field isn't a free-for-all. There are reserved IID values that have semantics - https://www.iana.org/assignments/ipv6-interface-ids/ipv6-interface-ids.xhtml. You need to make sure your SID values that you're going to put into an IPv6 DA field don't collide with these IID values when they are put in the IPv6 DA field. That's what complying with a protocol specification means, and that is what you need to do if you're *using* a protocol. Protocol specifications naturally inhibit innovation, because they have to. That is the cost of having interoperability with existing implementations. If SPRING want to innovate without constraint, then don't try to use an existing, widely deployed, 26 year old protocol. Invent a new local domain protocol that best suits your requirements. Otherwise, compromise on your solutions and mechanisms such that they still achieve what you want to achieve, while also complying with the IPv6 protocol specifications. <snip> Regards, Mark. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
