Re: All IPv6 fields are now mutable (Re: Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression)

On Sat, Oct 16, 2021 at 4:59 PM Mark Smith <markzzzsmith@gmail.com> wrote:
>
> On Sun, 17 Oct 2021, 06:36 Michael Richardson, <mcr@sandelman.ca> wrote:
> >
> > Mark Smith <markzzzsmith@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
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------