On Sat, Oct 16, 2021 at 4:59 PM Mark Smith <markzzzsm...@gmail.com> wrote: > > On Sun, 17 Oct 2021, 06:36 Michael Richardson, <m...@sandelman.ca> wrote: > > > > Mark Smith <markzzzsm...@gmail.com> 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/ > 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.
Mark, I think you might be lumping together several disparate proposals in your general claim that "IPv6 field immutability while the packet is in flight is also dead". When SRH was under discussion in 6man there was a lot of work to define which fields were immutable and that is described in RFC8754. Those definitions are sufficient to specify proper interaction between SRH and AH, however RFC8754 knowingly breaks AH as that handling was not specified. Some of us did object to that, but I suppose expediency to publish the protocol won out. Nevertheless, there is nothing that prevents someone from properly defining AH usage with SRH. As for the IPv6 destination address, it was never defined to be an immutable field inflight. In fact, the core operation of a routing header is to overwrite the destination address at each intermediate destination. NAT also changes the DA in flight, but there is a significant difference between NAT and the routing header header operation: when a routing header is set in a packet the sender knows and indicates the destination address. For the purposes of AH or transport checksum, both the sender and final receiver use this address-- there is no ambiguity and the fact that the destination address is mutable in flight doesn't adversely impact end to end protocol operations that operate on the addresses. We have seen various proposals to steal bits or redefine flow label fields, but IMO it's unlikely any of those will ever get consensus. Hosts routinely set the flow label as an unstructured value, and redefining flow label semantics would be a massive retroactive change in deployment. I would point out though, that the flow label is technically not immutable in flight, RFC6437 allows it to be modified by intermediate nodes for "only for compelling operational security reasons". Tom > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > i...@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
