|
Hi Brian,
please see my earlier
response to George. This really hinges on the exact functionality
assumed on the v6 host. What I don't understand is, once you decrypt
IPsec traffic which was originated by a v4 host, you are getting
honest-to-God IPv4 packets. There is no magic that will convert
encrypted packets from IPv4 to IPv6 in flight. So you need a v4 stack
to deal with these packets, it's not just a matter of understanding
IPv4 addresses. What am I missing?
Thanks,
Yaron
Brian E Carpenter wrote:
Yaron,
On 2008-03-31 00:33, Yaron Sheffer wrote:
Hi Marcelo,
see my responses inline.
Thanks,
Yaron
marcelo bagnulo wrote:
Hi Yaron,
thank you for your input, see some questions below...
Yaron Sheffer escribió:
I think we are bundling several different cases together. I will try
to enumerate the use cases, to clarify the situation a bit:
Case 1: v6-only host to v4-only host.
I don't think any IPsec solution can be crafted here.
So, in you opinion, if we have a v6 host communicating with a v4 host
a NAT64 in the middle, then they cannot communicate using IPSec,
neither transport nor tunnel mode directly between them. That includes
doing nor ESP nor AH nor IKE, is that correct?
Yes this is correct. A NAT box cannot do anything useful to either IKE
or IPsec unless it has access to the encryption keys, which would not
make sense in our case.
It seemed to me when I thought about this a few weeks ago that the
only solution would be a new form of SA specifically designed
to look like an IPv4-only SA but able to be created and checked
by a (suitably modified) IPv6-only host. And of course a similar
variant of IKE would be needed. I don't know if such variants
are possible, and they certainly require the IPv6 host to know the
pair of IPv4 addresses that the IPv4 host is using.
Brian
Scanned by Check Point Total Security Gateway.
|