On 05-Oct-21 10:15, Robert Raszuk wrote: > Hi Ron, > > Your below example has nothing to do with Internet Standard violation. > > You are free to define new ethertype and new IP header format any time you > wish to do so. > > Obviously it can not be called IPv6 any more as it is not compatible with > IPv6 IP header format. > > Main reason why SRv6 has chosen to use IPv6 is to make architecture > practically deployable and to make sure SR packets can be forwarded by legacy > nodes not SRv6 aware.
Isn't that the point of Ron's question? If the format of the DA field of a packet doesn't conform to the IPv6 address architecture, how can you call it an IPv6 packet, or expect the "legacy" node to do anything sensible? I have no intention of studying this work in detail, but if some present or future SID format happens to start with the bytes 0xfe80, a "legacy" node will certainly not forward a packet in which that SID occupies the DA space. I use the word "legacy node" because you do, but actually you mean "normal IPv6 node". SRV6 is the new kid on the block. More below... > > Best, > Robert. > > > On Mon, Oct 4, 2021 at 11:00 PM Ron Bonica > <rbonica=40juniper....@dmarc.ietf.org <mailto:40juniper....@dmarc.ietf.org>> > wrote: > > Brian, > > Is there any limit to the degree that one Internet Standard can violate > another, so long as that violation is constrained to a limited domain? > > For example, if I wanted to reduce the size of IPv6 header by shrinking > the source and destination addresses to 64 bits each, would that be OK? There is serious work on shortened addresses, I believe, but that work includes specifying what happens at the domain boundary. Apart from that, I've already cited my generic analysis of the question. https://www.rfc-editor.org/rfc/rfc8799.html#name-the-scope-of-protocols-in-l I wouldn't have co-authored that document if the IETF wasn't already standardizing quite a number of such protocols. As far as I know, there is no IETF or IAB document that takes a position on whether this is good, bad, or neutral. Brian > > Ron > _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
