> You're dealing, I believe, with getting IPSec across NATs. If > you expand the problem without separating it into its component > parts you run the very real risk of 1) completely re-engineering > IP, and 2) failing to respect layer boundaries. I'm not particularly > dogmatic about the latter, although I've found that egregious layer > violations tend to lead to routing problems/complexity, as routing > tables and routing updates need to be shoved from one layer > to another. Here IPSEC is likely to have beneficial effect on NAT by severely limiting the scope for NAT developers to mess with packets. This may mean that a number of protocols cannot be used behind a NAT, but this should not be a suprise since machines that are behind a NAT do not have an incomming address. Leave those problems for the Network Address Service Translation Yet (NASTY) working group. To take IPSEC to the next level we need to make IPSEC work well enough through a NAT that it can support SMTP client, HTTP client, POP3 client, IMAP client, NNTP client. We do not need to start addressing problems that have not been solved for NAT in general (and hacking up packets with protocol sensitive modifications is not a solution). The only way to fix those problems properly is to charter the NASTY working group to do a standards protcol for NAT discovery and port reservation and then deep integrate that into the IP stack so that when the call for 'give me a new socket' is made the IP stack sends a message off to the NAT box to request a port to be reserved. This probably does not require a degree in Nuclear Physics. If people stopped complaining about how anti-social NATs are and started working out how we could socialize them into more acceptable modes of behavior the degree of damage caused could be rendered tollerable. Phill
Phillip Hallam-Baker (E-mail).vcf