Hi Brian, Thank you - yes by legacy I meant not upgraded one - no different meaning intended.
As far as conforming to addressing architecture sorry to say but to me this is red herring. Sure address must be a legal address - no question. But what bits in the address mean is really up to the person allocating them. I can have perfectly valid set of IPv4 addresses which each assigned to different loopback of my node. Then each loopback is configured with completely different behaviour to the packets arriving to it. What matters for routing is the prefix - what matters for actually processing are the remaining bits. Same for IPv6. Kind regards, Robert On Tue, Oct 5, 2021 at 3:44 AM Brian E Carpenter < brian.e.carpen...@gmail.com> wrote: > 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
