[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NAT64 and IPsec support




On 01/04/2008, at 3:34 AM, Yaron Sheffer wrote:
As a newcomer to this group, it took me some time to understand (based on Hesham's response) that by a v6-only node people mean "dual stack with v6-only connectivity". And then I found out other regulars disagree... So I'm more confused than before.

=> My answer about ESP and IKE did not at all imply that the v6 node is also dual stacked. What I meant was that if the IKE daemon knows that it is talking to a v4 host, it can setup the SA with that IPv4 address knowing that packets will later be translated and the correct address will be received at the other end. Of course in my head this was all based on something like SIIT where the v6 node gets one IPv4 address all the time, i.e. no port translation. So I'm sorry for confusing people but I don't think this will work fior NAT64.

Hesham


Yes if you're dual stack, then you should be able to terminate normal IPv4-in-IPv4 IKE/IPsec, assuming the NAT64 box will simply forward the UDP/IPv4 (encapsulated-IPsec) packets as UDP/IPv6 packets, with no IPsec-specific intelligence.

Thanks,
    Yaron

George Tsirtsis wrote:
On Mon, Mar 31, 2008 at 12:59 PM, Iljitsch van Beijnum
<iljitsch@muada.com> wrote:

On 30 mrt 2008, at 13:33, Yaron Sheffer wrote:

 >>> In this case you could envision NAT64 happening on the host (!)
>>> which creates an IPv4-IPsec tunnel with its peer, encapsulates it
 >>> in UDP and sends it into the IPv6 network.

 >> right, but this not only requires v4 stack in the v6only node
>> (which would be ok, since as you say it seems this will be a common
 >> case for a while) but it also requires to provision a valid IPv4
>> address to the v6 only node and that address is not purely local, >> since it will be the v4 address the v4 only node has in its IPSec
 >> SA, right?
 >> So, even i agree this is possible i am not sure this is so
 >> interesting

> Actually we commonly provision such addresses to IPv4 clients today, > *inside* the IPsec tunnel. They are known as "Tunnel Inner Address
 > (TIA)". But I think I got this case wrong: you end up with a v4
 > packet, which you want to send to a v4 host, through a v6-only
 > network. It sounds more like tunneling than NAT.

What you have here is IPv4 packets that you tunnel, where one tunnel endpoint is IPv4 and the other is IPv6. So this requires translation
 of the outer header, bringing us back into NAT-PT territory.

 If IKE NAT traversal (RFC 3947) is supported on the v4 side the v6
 side can create a fake private IPv4 address and signal this as its
"real" address and everything should work. Basically, in this case the
 v6 host needs to act like an IPv4 host. This isn't entirely trivial
but I don't see any reason why it couldn't be done if IPsec over NAT-
 PT is desired over IPsec over IPv6.


GT> Iljitsch, it is for things like this that I earlier made the joke
about the fact that if we are going to add software to an IPv6-node we
should add an IPv4 stack. What is the point of getting an IPv6-only
node to be able to do all this fake-IPv4 instead of adding a proper
IPv4 stack to it? I understand that what you describe above does not
amount to a full IPv4 stack but still ....we have to assume at this
point that IPv4 is effectively both free and rather trivial.

GT> So, as Brian said in another e-mail we need to support the
unmodified IPv6 hosts to the extend we can, while we should also get
some benefit if the IPv6-only node is upgrade with some software e.g.,
for authenticated DNS. But I would still argue that the more complex
these changes are, the less sense they make sense, when compared to a
proper IPv4 stack. This line will of course always be hard to draw,
but we should try. These IPSEC extension IMHO fall on the wrong side
of such a line.

Regards
George

Scanned by Check Point Total Security Gateway.