I find it very difficult to understand the argument you appear to be trying to make. Wait for IPv6 is not an acceptable solution. If nothing is done until IPv6 is deployable the vendors will long since have taken their IPSEC standards business to another forum. You appear to be arguing that 1) The group should do nothing to accomodate NAT 2) The proposal to provide minimal accomodation of NAT is insufficient. So which is it? Both arguments may point to 'do nothing' but they are inconsistent. When I see that type of bifurcated argument being made I suspect that the true position is 'I don't want to accomodate NAT in any circumstance whatsoever but I will be opportunistic in my arguments'. NAT introduces some intrinsic problems with any protocol that opens up a listening port. IPSEC will inevitable screw up sone of the kludges and work-arrounds out in the wild. I don't think that is a problem, demand for IPSEC is much stronger than any of the protocols affected by the kludges that will be broken. The Internet may be about much more than client side HTTP and email, however if you are behind a NAT box that does not provide for a principled support for advertising a listening port to the NAT you should probably learn not to expect very much more. The problem is at that point outside IPSEC scope. IPv6 does not eliminate the need for NAT, in fact some companies will be deploying NAT to conceal leakage of ethernet MAC addresses and the like from their domain that people seem to want to encode into IPv6 addresses. One of the uses of NAT is to provide an auditable means of determining whether the trafic on a network segment is compliant with the routing policy or not and in particular whether there is an unauthorized bridge to an external network in operation. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227
Phillip Hallam-Baker (E-mail).vcf