On 18-Oct-21 09:39, Tom Herbert wrote: > 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".
Correct, because it was very clear that some firewalls were going to clobber it whatever we wrote. So we tried to describe behaviour that would not nullify the usefulness of the field for stateless load balancing. As for draft-filsfils-6man-structured-flow-label, the problems in https://mailarchive.ietf.org/arch/browse/ipv6/?gbt=1&index=qrTou1rjtNDDchE5yFfSN31pkMc remain unsolved. Brian _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
