On Wed, Dec 31, 2025 at 5:35 PM Mark Smith <[email protected]> wrote: > > 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.
Hi Mark, AH only protects Version, Next Protocol, Addresses, and Payload Length. WIth the exception of the Addresses corruption of the other fields will most likely result in packets being dropped. > > 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. I understand your point, but AFAIK no one is using AH for the purposes of preventing NAT. Unless AH is actively being deployed, the mere threat that AH might someday be deployed doesn't seem like a very compelling argument to prevent people from using NAT with IPv6. Also, NAT isn't the only actor. As I mentioned in the paper checksum offload breaks with AH. If we can't do checksum offload then the checksum needs to be computed in the CPU at pretty high cost in CPU cycles and power. I don't think there's going to be many takers willing to turn off checksum offload for the trade off of discouraging NAT with IPv6. Tom > > 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]
