On 28 mrt 2008, at 20:14, marcelo bagnulo wrote:
Another issue that was brought up during the meeting was IPSec support.I have been reading RFC3948 and i have some questions.I understand that if transport mode can work through v4 NATs using RFC3948 UDP encapsulation and soem other tweaks defined in the RFC, then it is reasonable to expect that the same level of support of support can be achieved in NAT64. so we could simply add a requirement that NAT64 mechanisms should support the use cases supported by RFC3948.
Ok, this is all easy enough (and should equally apply to both tunnel and transport mode), except that RFC 3948 doesn't really mention IKE, which I think needs to be changed to support NAT64 or NAT46. Question to the IPsec experts: would it be possible to have the updated IKE implementation on just one end (presumably the v6 end) where the other end thinks it just sees regular NAT44?
In tunnel mode, we have two IP headers and the NAT64 will only translate one of them (by default, if we don't do anything special with it). so, the problem, is that even if the outside IP header is translated with the NAT64 box, the inner header remains in the original IP version, so i am wondering if this doesn't present additionla difficulties. The option is to translate both headers
The inner header is encrypted and/or protected by a HMAC so translating it is not possible. However: there are two possibilities:
1. The inner header is IPv6. In that case, it seems reasonable that IPv6 could also be used for the outer header so the issue is moot
2. The inner header is IPv4. In that case, no translation is required so the issue is also moot