Mark, I seriously wonder as I see all this if it wasn’t a mistake to not declare srv6 an entirely new protocol with a new protocol number back at the start of this.
Because it looks more and more like Robert was right when he said that srv6 was not ipv6 - that or we seem to have forgotten the very basics of standardization. The problem here is that it seems to be a slow drift - and the delta between these minor corruptions of each aspect of the specification in each new draft is small enough that we seem to be content to let it slide. Unfortunately each time this happens - the delta between the original spec and whatever we have by the time we take all of this combined is well - rather large. Sooner or later we are going to have to decide - continue to allow the protocol to mutate while still claiming it is ipv6 - or do what maybe should have been done in the first place - give it a new protocol number and let people decide if they want ipv6 or whatever this is. Andrew Get Outlook for iOS<https://aka.ms/o0ukef> ________________________________ From: ipv6 <[email protected]> on behalf of Mark Smith <[email protected]> Sent: Sunday, October 17, 2021 2:58:08 AM To: Michael Richardson <[email protected]> Cc: 6man WG <[email protected]>; SPRING WG <[email protected]> Subject: All IPv6 fields are now mutable (Re: Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression) On Sun, 17 Oct 2021, 06:36 Michael Richardson, <[email protected]> wrote: > > Mark Smith <[email protected]> wrote: > > In fight changing DAs also will break AH protection of the IPv6 header. > > AH is dead. It's been dead for decades. > I say this as an IPsec enthusiast who wishes this wasn't true. > But it is. Then all IPv6 field immutability while the packet is in flight is also dead. "Controlled domain" == redefine any field, field semantics, and field processing we like in an existing protocol, yet claim we're still using the original protocol. That has been tacitly endorsed via standards track RFC8986. The Next Header field is not supposed to be modified in flight per internet standard RFC8200, yet standards track RFC8986 specifies the behaviour via PSP. This SRH compression ID is redefining the IPv6 DA field semantics. It encodes multiple network hop destinations in the single IPv6 destination address field. Structured Flow Label - https://datatracker.ietf.org/doc/draft-filsfils-6man-structured-flow-label/<https://datatracker.ietf.org/doc/draft-filsfils-6man-structured-flow-label> is redefining the IPv6 flow label field. This will be an operational nightmare in the future, when there are multiple applicable RFCs that conflict with each other. I don't want to have to spend time getting into arguments with vendors about which protocol variant RFC their implementation should or shouldn't have to comply with while I have 1000s, 10s or 100s of 1000s of customers off-line. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://www.ietf.org/mailman/listinfo/ipv6> --------------------------------------------------------------------
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
