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

Reply via email to