Re: [IPv6] Removing extension headers from packets (revisited)

[Mark Smith <[e-mail]>]

On Sat, 19 Aug 2023, 03:50 Tom Herbert,
<tom=[e-mail]> wrote:
>
>
>
> On Fri, Aug 18, 2023, 9:19 AM Ole Troan <otroan=[e-mail]> wrote:
>>
>> > That code makes lots of assumptions.   First, it assumes a software router.  Second, it assumes there is exactly one EH to be removed, and it is in a position that is known a priori.  And many other bits and pieces.
>>
>> It would be hard to not understand that what I gave was purely a concept and not “code”.
>> The HBH header is always at a fixed position. And I think we are far enough down the path of allowing a HBH option to require for it to limit itself to a single option.
>>
>> The point though, stands, the claim that header removal cannot be allowed in standards because it is hard to do in hardware seems very weak.
>
>
> I'll post a draft shortly, but I think the requirements are something like:
>
> An HBH EH (that immediately follows IPv6 header) MAY be removed unless the packet contains an Auth EH



It's going to be quicker to generalise and say all IPv6 fields are
mutable, which implicitly means EHs can be inserted or removed
in-flight (i.e. mutable next-header field) and that field definitions
are only suggestions, unless the AH header is present..

c.f. SPRING CSID redefines the Destination Address (singular) field to
carry multiple destinations.

Also remove any of the IPv6 fields being included in the transport
layer checksums. Probably a layer violation in the first place anyway
and a carry over from when IP was part of the TCP protocol.

Finally, deprecate ICMPv6 unless the AH is protecting the packet for
which the ICMPv6 message is going to be generated. Although we don't
care much for operators here, receiving no ICMPv6 message would be
more useful than receiving a misleading inaccurate one when it isn't
possible to easily tell if the received ICMPv6 message is accurate.

The principle of least astonishment demands being frank about what
actually is and isn't allowed, rather than piecemeal modifications to
RFC 8200 hidden away in a variety of other RFCs.


>
> A routing header MAY be removed if:
>
> - The final destination has been set in the DA
> - And there are no extension headers that preceed the routing header (except if it is immediately preceeded by a HbH header that is also being removed)
> - And the packet does not contain an Auth EH
>
> Additionally, for segment routing header, maybe the SRH SHOULD NOT be removed if it contains options
>
> Tom
>
>>
>> O.
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------