[IPv6]Re: Fwd: New Version Notification for draft-herbert-deprecate-destops-before-rh-00.txt

[Tom Herbert <[e-mail]>]

On Mon, Dec 29, 2025 at 10:15 AM Jeremy Duncan
<jduncan=[e-mail]> wrote:
>
> Hi Tom-
>
> First, the first sentence of the intro is a bit confusing with the reference of which article "it" is:
>
> 1.  Introduction
>
>    This document deprecates IPv6 Destination Options before the Routing
>    header since there are no known deployments or uses for it.
>
> Recommend rewriting to something like:
>
> 1.  Introduction
>
>    This document deprecates IPv6 Destination Options before the Routing
>    header since there are no known deployments or uses for the Destination Options Header placed ahead in precedence of the Routing Header.
>
>

Hi Jeremy,

Thanks for the comments!

> Second, you state that the problem we are solving is two-fold:
>
> 1. because no one uses Destination Options for intermediate uses
> 2. intermediate nodes are already using things like the SRv6 routing header, HbH, or the routing header.
>
> However, instead of merely deprecating its use for intermediate devices before routing header, is there a broader argument for just deprecating it completely instead?
> I struggle to find Destination Options in real-world use on end-node destinations as well.

It's a fair question :-), but if we try to deprecate Destination
options completely I suspect that's going to get a lot of pushback
since it's "irreversible" and there are a few potential use cases in
limited domains like improved fragmentation. IMO, limiting the use
cases by zapping DestOpts before RH, restricting them to limited
domaIns, and disabling them by default in host implementations is
sufficient for the time being to eliminate most of the problems
without completely closing the door on the feature ever being
productively used.

Tom

>
> Thoughts?
>
>
> -Jeremy
>
> -----Original Message-----
> From: Tom Herbert <tom=[e-mail]>
> Sent: Monday, December 29, 2025 11:40 AM
> To: 6MAN <[e-mail]>
> Subject: [IPv6]Fwd: New Version Notification for draft-herbert-deprecate-destops-before-rh-00.txt
>
> [EXTERNAL] Verify links and attachments with sender.
>
> Happy holidays 6MAN!
>
> I've posted a new draft to deprecate Destination Options before the Routing header and to require the Routing header to either  follow
> IPv6 header or Hop-by-Hop Options header with at most one Routing header in a packet. Comments are appreciated!
>
> Thanks,
> Tom
>
>
> ---------- Forwarded message ---------
> From: <[e-mail]>
> Date: Mon, Dec 29, 2025 at 8:36 AM
> Subject: New Version Notification for
> draft-herbert-deprecate-destops-before-rh-00.txt
> To: Tom Herbert <[e-mail]>
>
>
> A new version of Internet-Draft
> draft-herbert-deprecate-destops-before-rh-00.txt has been successfully submitted by Tom Herbert and posted to the IETF repository.
>
> Name:     draft-herbert-deprecate-destops-before-rh
> Revision: 00
> Title:    Deprecate IPv6 Destination Options Before the Routing Header
> Date:     2025-12-29
> Group:    Individual Submission
> Pages:    7
> URL:      https://www.ietf.org/archive/id/draft-herbert-deprecate-destops-before-rh-00.txt
> Status:   https://datatracker.ietf.org/doc/draft-herbert-deprecate-destops-before-rh/
> HTMLized: https://datatracker.ietf.org/doc/html/draft-herbert-deprecate-destops-before-rh
>
>
> Abstract:
>
>    This document deprecates Destination Options before the Routing
>    header.  It also requires that if a Routing header is present in a
>    packet then it must immediately follow the IPv6 header or immediately
>    follow the Hop-by-Hop Options header if an Hop-by-Hop Options header
>    is also present in the packet.  These requirements imply that at most
>    one Routing header may be present in a packet.
>
>
>
> The IETF Secretariat
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> List Info: https://mailman3.ietf.org/mailman3/lists/[e-mail]/
> --------------------------------------------------------------------