Hi,
On Thu, 1 Jan 2026, 08:13 Brian E Carpenter, <[email protected]> wrote: > Hi, > > I'm no expert, but I think the Security Area might have an opinion on this. > > Note that according to RFC 8221: > > "The last method that can be used is ESP+AH. This method is NOT > RECOMMENDED." > > "ENCR_NULL status was set to MUST in [RFC7321] and remains a MUST to > enable the use of ESP with only authentication, which is preferred > over AH due to NAT traversal." > NAT traversal is only supposed to be an issue in IPv4. Allowing NAT on IPv6, by deprecating the only mechanism that can protect against it, that is, AH, will only encourage its use, because "What you allow, you encourage." - Michael Josephson. If NAT is encouraged in IPv6, what is the point of IPv6? NAT imposes client/server roles at the network layer. Devices behind the NAT can't or can't easily act as servers or equal peers to other network layer devices. They become clients only by default. For example, in a multipath transport protocol, how can a node announce its own addresses to a peer, to establish further sessions, when it doesn't know what its outside addresses are, because it's behind a NAT. NAT is really reverting to the dumb terminal/mainframe service model of the 60s, only these days the mainframe operators would be the major cloud operators. Deprecating AH is effectively saying that any and all IPv6 header fields are allowed to be mangled in any way by the network, because there would be no way to protect against it. We have never had NAT in E.164 phone numbers of the past 100+ years. We all expect our phones to be able to equally and as easily send and receive phone calls. Why can't we make sure that our computers have that capability too? I'd ask anybody who thinks NAT is a good idea if they would accept only being able to make phone calls on their smartphone, but never be able to receive them, or be able to tell people their phone number. Regards, Mark. > "As mentioned by [RFC7321], it is NOT > RECOMMENDED to use ESP with NULL authentication (with non- > authenticated encryption) in conjunction with AH; some configurations > of this combination of services have been shown to be insecure > [PD10]." > > That seems pretty close to deprecation already. > > Regards/Ngā mihi > Brian Carpenter > > On 01-Jan-26 09:01, Tom Herbert wrote: > > Happy New Year! > > > > I've posted a new draft that would formally deprecate the IP > > Authentication Header. Any comments are appreciated. > > > > Thanks, > > Tom > > > > > > ---------- Forwarded message --------- > > From: <[email protected]> > > Date: Wed, Dec 31, 2025 at 11:58 AM > > Subject: New Version Notification for > draft-herbert-deprecate-auth-header-00.txt > > To: Tom Herbert <[email protected]> > > > > > > A new version of Internet-Draft > draft-herbert-deprecate-auth-header-00.txt has > > been successfully submitted by Tom Herbert and posted to the > > IETF repository. > > > > Name: draft-herbert-deprecate-auth-header > > Revision: 00 > > Title: Deprecate IP Authentication Header > > Date: 2025-12-31 > > Group: Individual Submission > > Pages: 14 > > URL: > https://www.ietf.org/archive/id/draft-herbert-deprecate-auth-header-00.txt > > Status: > https://datatracker.ietf.org/doc/draft-herbert-deprecate-auth-header/ > > HTMLized: > https://datatracker.ietf.org/doc/html/draft-herbert-deprecate-auth-header > > > > > > Abstract: > > > > This document deprecates the IP Authentication Header. The > > motivations are that authentication without confidentiality is not > > compelling, the Authentication Header is incompatible with some > > commonly deployed protocols, and there is likely no deployment of > > Authentication Header. > > > > > > > > The IETF Secretariat > > > > _______________________________________________ > > Int-area mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > List Info: https://mailman3.ietf.org/mailman3/lists/[email protected]/ > -------------------------------------------------------------------- >
_______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
