Bill Sommerfeld writes: > UDP_NAT_T_- Committed If applied to a UDP/IPv4 socket, > ENDPOINT outbound packets send via the socket [...] > + Source and destination address extensions reflect outer-header selectors > + for an IPsec SA. An SA is inbound or outbound depending on which of [...] > + NAT-T local and NAT-T remote addresses store local and remote ports > + used for ESP-in-UDP encapsulation. A non-zero local NAT-T address
Just checking that I understand how this works ... The idea is (roughly) that some application opens a regular UDP socket, binds and connects it, and then sets the UDP_NAT_T_ENDPOINT option. It then uses the PF_KEY interfaces to specify those same source/destination address values and local/remote port values (perhaps fetched from the UDP socket via getsockname/getpeername) to tell the kernel to "wire" ESP into that particular UDP socket. This causes ESP-in-UDP packets on the socket to match, be vectored out, and processed as expected to find inner stuff. Is the reason why it's IPv4-only because NAT and other evil protocol filters on IPv6 are considered "really unlikely?" -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
