Hi Mark, Ok the argument of IID space comes first time - I do apologies if I missed it and it was mentioned before.
So the consequence of reserved IID space for application A in case of collision with any other application B may yield unexpected results. And that apparently is completely agnostic to the actual prefix of the address. But reading say RFC6543 such IIDs can be present only in link local addresses not real IPv6 "global" prefixes. So again we are safe. If there any case that IPv6 stacks are expected to perform any action based on the IIDs of the packets irrespective of the prefix/locator portion of the DST address in the packet header ? Thx, R. On Thu, Oct 7, 2021 at 2:29 PM Mark Smith <markzzzsm...@gmail.com> wrote: > 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
