Yes, the idea is to make it possible to leverage native ESP. Pretty much all IPv6 networks (at least commercial networks) don't do NAT. But some of them drop ESP packets. On these networks, NAT detection will say there is no NAT, and the ESP session will be established, but no traffic will flow.
On Tue, Mar 26, 2024 at 6:24 PM Panwei (William) <william.pan...@huawei.com> wrote: > Hi, > > I've read the draft and I think I can understand the solution part. But > please allow me to ask a stupid question about the motivation or use case, > because I'm a little confused about that. > > I feel that the problem of IPv6 ESP traverse failure, as described in the > draft and presentation slides, is because of NAT. IKEv2 already supports > the detection of NAT. After the detection of NAT, the peers can use IP + > UDP (4500) + ESP to traverse the NAT. Are there some use cases that this > existing solution doesn't work and this draft tries to solve? Or, are there > some use cases that IKEv2 fails in detecting the existence of NAT? > I can understand the advantages of native ESP described in the draft: 1) > no keepalives or fewer keepalives, 2) no overhead of UDP header. Does this > draft target the use cases where IP + UDP + ESP and IP + ESP can both work > in the existence of NAT, and try to benefit from the native ESP? > > Regards & Thanks！ > Wei PAN (潘伟) > > > -----Original Message----- > > From: IPsec <ipsec-boun...@ietf.org> On Behalf Of Jen Linkova > > Sent: Thursday, February 29, 2024 11:28 PM > > To: ipsec@ietf.org > > Cc: Lorenzo Colitti <lore...@google.com>; Michael Richardson > > <mcr+i...@sandelman.ca> > > Subject: [IPsec] Fwd: New Version Notification for > > draft-colitti-ipsecme-esp-ping-01.txt > > > > -01 version shall address comments received since -00. > > The main change is that payload format is defined similarly to ICMPv6 > > echo, and the draft now updates RFC4303, so ESP packets with SPI == 7 > > or 8 and next header==59 are not considered to be dummy packets. > > > > Comments are appreciated! > > > > > > ---------- Forwarded message --------- > > From: <internet-dra...@ietf.org> > > Date: Fri, Mar 1, 2024 at 2:24 AM > > Subject: New Version Notification for > > draft-colitti-ipsecme-esp-ping-01.txt > > To: Jen Linkova <furr...@gmail.com>, Lorenzo Colitti > > <lore...@google.com>, Michael Richardson > > <mcr+i...@sandelman.ca> > > > > > > A new version of Internet-Draft draft-colitti-ipsecme-esp-ping-01.txt > > has been successfully submitted by Jen Linkova and posted to the IETF > > repository. > > > > Name: draft-colitti-ipsecme-esp-ping > > Revision: 01 > > Title: ESP Echo Protocol > > Date: 2024-02-29 > > Group: Individual Submission > > Pages: 7 > > URL: > > > https://www.ietf.org/archive/id/draft-colitti-ipsecme-esp-ping-01.txt > > Status: > > https://datatracker.ietf.org/doc/draft-colitti-ipsecme-esp-ping/ > > HTML: > > > https://www.ietf.org/archive/id/draft-colitti-ipsecme-esp-ping-01.html > > HTMLized: > > https://datatracker.ietf.org/doc/html/draft-colitti-ipsecme-esp-ping > > Diff: > > > https://author-tools.ietf.org/iddiff?url2=draft-colitti-ipsecme-esp-ping- > > 01 > > > > Abstract: > > > > This document defines an ESP echo function which can be used to > > detect whether a given network path supports IPv6 ESP packets. > > > > > > > > The IETF Secretariat > > > > > > > > > > -- > > Cheers, Jen Linkova > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec >
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
