Re: What is necessity for SRH, and other EH, insertion/removal?

[[e-mail]]

On 2019-12-18 14:07, Tom Herbert wrote:
> On Sat, Dec 7, 2019 at 9:17 AM Tom Herbert <[e-mail]> wrote:
> >
> > Pulling this out into a separate thread. Pertinent questions are:
> >
> > Why is extension header insertion and removal at necessary?
> >
> > Why isn't the proposed alternative of IPIP encapsulation sufficient?
> > (where the encapsulating headers contain the extension headers that
> > would otherwise be inserted)
> >
> I believe that inband network telemetry (INT and IOAM ) might provide
> the best motivation for extension header insertion. One of the goals
> is to allow network operators to perform telemetry on packets as they
> traverse their network. A telemetry header, INT or IOAM, is put into
> packets on ingress to the domain and removed at egress, and
> intermediate nodes modify the packet with measurement data.
> 
> Key requirements are that not all packets for a flow need to be
> measured, and measured packets need to follow the same path as those
> not measured  in order for the measurements to reflect what is
> happening for the flow. IPIP encapsulation would change the hash that
> ECMP uses so encapsulated packets might traverse a different path--
> therefore it's not sufficient in this case. Extension header insertion
> would maintain the routing in ECMP (although the fact that extension
> headers aren't supported in IPv4 creates another problem).
> 
> Some of the inband telemetry implementations are already addressing
> this by inserting the inband telemetry headers directly into the UDP
> or TCP payload of existing packets and removing the inserted payload
> bytes at the egress point. Since only transport payload is being
> modified, the packets will be routed the same way as other modified
> packets for a flow. The obvious problem with this approach is that
> payload is being changed by intermediate nodes such that if the end
> host were to ever receive the modified packet this could result in
> silent data corruption of users' data. So this protocol mechanism is
> fundamentally not robust and probably dangerous. I think this actually
> makes extension header insertion, where the worst case scenario is
> probably unexplained packet loss, look palatable!

Explained that way, it evoked this thought: Put telemetry in a
trailer [cf. RFC893]. If conforming IPv6 implementations expect
there's no information after the nominally final octet of a
packet, then they'll neglect to forward (the trailer) onward?
QED! No escape to the "open" Internet, no munged ECMP hash, no
header insertion. Obvs, processing trailers on the fast path is
... problematic.