On Fri, Jan 2, 2026 at 9:36 AM Robinson, Herbie <[email protected]> wrote: > > > There are literally billions of computers connected to the Internet (not > counting mobile phones). How can you prove that a feature isn't being used?
Hi Herbie, We cannot prove no one is using it, however given the fact NAT breaks AH and AH would break checksum offload (at least in LInux) the vast majority of billions of computers couldn't use AH even if they wanted to. > > Putting out a warning and saying "No-one complains" doesn't cut it, because a > lot of users ignore warnings and it's impossible to check a billion computers > for warnings. It's not just a buried warning, if someone wanted to use AH they would need to manually enable it and would be aware that they are enabling a deprecated feature. > > This really comes down a judgement call and it depends on what feature you > are talking about and what system you are talking about. > > Arguments for removing deprecated features: > o You remove the risk of users who still use it hitting bugs. > o You remove the cost of any maintenance. > > Arguments against removing deprecated features: > o Users will never upgrade any of their systems to pick up bug fixes because > they don't have time to reconfigure something, or worse, because they have an > old system that is critical to their business and they can't upgrade it. > This will hurt your reliability numbers much more than having unused AH code > sitting in there. One of the things we learned early on at Stratus is that > the single biggest factor in terms of overall system reliability is getting > users to update to the latest bug fix release. They won't do that if you > make incompatible changes.\ > > o You will spend more time fielding the angry complaints from customers who > are unable to figure out why you suddenly broke it (that's always their > perspective) than you would leaving the feature in. Note that it usually > works to tell customers you don't fix bugs in deprecated features; so, the > maintenance load for leaving them in is very little. This happens all the time in operating systems. Features that are unused have been removed and backwards compatibility is limited to several versions. > > So, my point is that, yes, we should deprecate AH, because it's a maintenance > nightmare from the standpoint of implementing new features. But we shouldn't > be assuming that "deprecate" means it's going to actually disappear any time > soon. From the IETF point of view, "deprecate" can only mean we aren't going > to update any new standards to accommodate AH. I understand the concerns, but nothing is forever. I like the definition of deprecated as "something (like a software feature, standard, or hardware) is marked as outdated, no longer recommended for use, and scheduled for eventual removal". As I mentioned we can take a phased approach to mitigate any potential issues and the whole process would probably take a few years-- but it is a clear path towards removal of AH from the implementation. The alternative is to commit to supporting AH and every other IETF protocol ever defined in perpetuity-- that's just not realistic from an implementation POV. Tom > > > -----Original Message----- > > From: Tom Herbert <[email protected]> > > Sent: Friday, January 2, 2026 11:51 AM > > To: Robinson, Herbie <[email protected]> > > Cc: Fernando Gont <[email protected]>; int-area <[email protected]>; > > 6MAN <[email protected]> > > Subject: Re: [Int-area] Re: [IPv6]Re: Fwd: New Version Notification for > > draft- > > herbert-deprecate-auth-header-00.txt > > > > On Fri, Jan 2, 2026 at 8:33 AM Robinson, Herbie > > <[email protected]> wrote: > > > > > > This might be an unusual case, because IKE can negotiate around it, but in > > general, assuming you can remove a feature you’re your because the IETF has > > deprecated it will get you into trouble with your customers/clients or > > whatever. > > The practical meaning of deprecated means you don’t have to support it in > > new > > implementations and should try to stop fixing bugs in it. In the case of > > AH, > > deprecation means that we don’t have to figure out what to do about every > > new > > case where it’s incompatible with some new Internet protocol (or the > > existing > > places where it doesn’t work). > > > > Herbie, > > > > If a protocol is deprecated that should mean that no one is using it or the > > code > > that implements it. In that case, we want to remove unused code from > > implementations because maintaining the it is not without cost and > > unused/untested code becomes a liability and a risk when someone tries to > > use > > it. > > > > To deprecate a protocol like this we can take a phased approach that has > > been > > used for other features being deprecated. First, we'll disable it to be > > compiled > > by default and give a nice warning that the protocol is being deprecated. > > Once > > that's fully deployed and if no one complains the feature is being > > deprecated > > then the code for the protocol can safely be removed. > > > > Tom > _______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
