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

Re: NAT64 and IPsec support



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.


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.