Sabahattin Gucukoglu wrote: >> nor IPv6, especially because NAT can be end to end transparent. > How do you propose to make end-to-end crypto of packets possible > where NATs are involved? My proposal in draft-ohta-e2e-nat-00.txt is to use 32 bit SPI as 16 bit source and destination port numbers: The same location may be usable for some protocols. For example, ESP packets may be demultiplexed based on the lower 16 bit of SPI. To do so, a destination host must be able to control the lower 16 bit of SPI. Other protocols may use different location, for which E2ENAT may provide special care. Considering that an ICMP packet generated against an IP packet contains only the first 64 bits of payload of the original packet, demultiplexing information for source transport is implicitly assumed to be located in the 64 bits. So, it is natural that demultiplexing information for destination transport is also located in the same field. If the information is 16 bit word and 16 bit aligned, there are only four variations on the location. This memo assumes so. For example, AH packets may be demultiplexed as if the lower 16 bit of SPI, located at the seventh and eighth bytes of a payload, is a destination port number. Though existing NAT boxes may not support such behavior, upgrading is necessary only by those who want to use IPSEC behind NAT. > I'm assuming you think everything can be solved with signalling, > yes? I ask because NPT could be the end of it if we all agreed > to use the right kind of signalling. Signaling between what? SPI negotiation may be called signaling. Masataka Ohta