Subject: NAT64 and IPsec support

From: marcelo bagnulo <[email-masked]>
Date: Fri, 28 Mar 2008 20:14:31 +0100

Hi,

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.

However, i am not so clear about the tunnel mode.
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, but this again will be different 
than the IPv4 NAT case, since the inner header in the IPv4 NAT case 
remains unchanged, while we would be changing it in this case. So i am 
finding that the tunnel mode wouldn't be so directly supported using the 
IPv4 NAT traversal techniques for IPSec.

However, i am not an expert on this, so i may get this completelly 
wrong. any guidance on this would be appreciated

Regards, marcelo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 28 Mar 2008 21:10:56 +0100

On 28 mrt 2008, at 20:14, marcelo bagnulo wrote:

> 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.

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 28 Mar 2008 21:34:49 +0100

On 28 mrt 2008, at 21:10, Iljitsch van Beijnum wrote:

> 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?

Wait: this is only an issue if the IPv6 hosts thinks it's actually  
doing v6. In that case, I don't see how IKE could work (but IKE is  
extremely complex and I only know how it works very superficially). If  
on the other hand the host knows it's talking to a v4 destination it  
can anticipate the translation and it should probably be possible to  
make things such that IKE can work the same way as though NAT44.

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 29 Mar 2008 11:27:08 +1100

> additionla difficulties. The option is to translate both headers,

=> But how can you translate the inner header if it's covered with  
ESP? You can't see the inner header at all.

Hesham

> but this again will be different than the IPv4 NAT case, since the  
> inner header in the IPv4 NAT case remains unchanged, while we would  
> be changing it in this case. So i am finding that the tunnel mode  
> wouldn't be so directly supported using the IPv4 NAT traversal  
> techniques for IPSec.
>

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 29 Mar 2008 11:31:45 +1100

On 29/03/2008, at 7:34 AM, Iljitsch van Beijnum wrote:
>> 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?
>
> extremely complex and I only know how it works very superficially).  
> If on the other hand the host knows it's talking to a v4 destination  
> it can anticipate the translation and it should probably be possible  
> to make things such that IKE can work the same way as though NAT44.

=> IKE can work with, for example, mapped addresses, it sets up the SA  
based on the v4 address. I think this was discussed in either SIIT or  
in:
http://www.tools.ietf.org/html/draft-ietf-ngtrans-siit-dstm-00

or in both, I can't remember now.

Hesham

---

From: marcelo bagnulo <[email-masked]>
Date: Sat, 29 Mar 2008 11:05:03 +0100

Iljitsch van Beijnum escribió:
>> 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
>

no, there are no possibilites then.
I mean,
if the v4 only host don't understand v6
and
the v6 only host don't understand v6,
and
the inner header cannot be changed (so it is v6 or v4)
Then
we cannot make this work, i.e. there is no possible IPSec tunnel mode 
support,
since the inner header is either:
v4, then the v6 only node doesn't understand it
or
v6 then the v4 only node doesn't understand it

So, my conclusion is that we cannot require IPSec tunnel mode support in 
the NAT64 environment

We can require transport mode support, if we can work out the details

what am i missing?

regards, marcelo

---

From: "George Tsirtsis" <[email-masked]>
Date: Sat, 29 Mar 2008 10:14:16 +0000

Iljitsch/Marcelo,

I am a bit confused by this discussion. See below.

>  IPv6 could also be used for the outer header so the issue is moot

GT> Yes, this works only if the stab network and/or the NAT64 box has
an IPv6 way of reaching the destination, which is fine.

>  so the issue is also moot

GT> But then the NAT64 box is irrelevant.
The only thing we have to make sure for both of these cases is that
NAT64 does not interfere with native IPv4 and native IPv6 traffic.

GT> The only question in my mind that is relevant to the NAT64
discussions, is whether IKE/IPSEC, can work between an IPv6only node
and an IPv4only node. IMHO there is something perverse about expecting
such a thing to work and I would just forget about it.

GT> Note that in IPv4NAT, one can tunnel over it, meaning that NATv4
is applied only on the (non-secured) tunnel header and the inner
header can be IPSECed with no problems. When the two peers do not
speak the same IP version, however, such an approach does not help
i.e., all IP-layer headers will require translation which will always
break IPSEC

GT> So, unless we are talking about IKE/IPSEC that somehow does NOT
cover IP-layer headers, I do not think any solution to this exists.
But maybe I am missing something?

Regards
George

---

From: marcelo bagnulo <[email-masked]>
Date: Sat, 29 Mar 2008 11:25:33 +0100

> and an IPv4only node. 
exactly!

> IMHO there is something perverse about expecting
well, it seems that people expect that things that work on a regular 
v4NAT shoudl also work in NAT64, so i would like to see if we can 
require that.
Some flavors of IPSec does work through v4NATs. see RFC3948

> i.e., all IP-layer headers will require translation which will always
that is exactly my point
So IPSec tunnel mode, even if it is supported in v4NATs seems hard to 
support in NAT64, since each of the peers only speack one IPversion and 
the inner IP header cannot be changed

> cover IP-layer headers, 
yes, there seems to be one of such cases, which is IPSec transport mode 
the so called telecommuter scenario

it seems possible to me (whit my incredilble limited knowledge on IKE) 
that this could work

So my current proposal is to require to support the teleconmuter scenario

Regards, marcelo

> I do not think any solution to this exists.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 29 Mar 2008 14:53:11 +0100

On 29 mrt 2008, at 11:25, marcelo bagnulo wrote:

> So IPSec tunnel mode, even if it is supported in v4NATs seems hard  
> to support in NAT64, since each of the peers only speack one  
> IPversion and the inner IP header cannot be changed

But wouldn't most hosts, even if they only have IPv6 connectivity,  
usually also support IPv4 in their stack during the transition period?  
I can imagine that constrained devices may want to drop IPv4 support  
but it's hard to imagine devices that are willing to run IPsec but are  
too constrained to support IPv4.

It starts to look to me that the IPv6 side in a NAT64 scenario could  
possibly do everything that's needed to make IPsec work through NAT64  
the same way it today works through NAT44, with only minimal  
cooperation from the NAT box.

> yes, there seems to be one of such cases, which is IPSec transport  
> mode the so called telecommuter scenario

Note that IPsec transport mode is rarely used in practice.

---

From: marcelo bagnulo <[email-masked]>
Date: Sat, 29 Mar 2008 17:46:49 +0100

Iljitsch van Beijnum escribió:
>> support in NAT64, since each of the peers only speack one IPversion 
>> and the inner IP header cannot be changed
>

i may agree with the point that v6 only hosts will have an IPv4 stack, 
but in order to make it work, we not only need to have the v4 stack but 
also the v4 address, which needs to be present in the IPSec SA in the 
IPv4 only hosys (i.e. it is an IPv4 address that will be known by the peer)

So, if we assume that this is possible, then we are in the dual stack 
scenario, then we simply need a tunnel between a dual stack host and an 
IPv4 only host, which is not the application scenario for NAT64 imho

So, the application scenario for NAT64 seems to imply that we cannot 
assume IPv4 address available in the ipv6 only host

In summary, i still think that IPSec tunnel case cannot be supported in 
NAT64 scenario

> cooperation from the NAT box.
i still cannot agree with that
regards, marcelo

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 30 Mar 2008 08:43:15 +0200

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.

Case 2: one IPsec gateway (a common remote-access deployment).

v6-only host ==== (v6-only connectivity) === (optional v4 network) ==== 
IPsec Gateway ======== v4-only host

We can use normal IPv6 IPsec in tunnel mode between the v6 host and the 
gateway, followed by NAT64 on the v4 side.

I'm not sure what the gateway will do if we also have NAT64 on the 
left-hand side and IPsec traffic is then encapsulated in UDP/IPv4. We 
might need to require IPsec peers to allow this situation. Note that in 
this sub-case, the encrypted traffic is never touched, only the UDP 
encapsulation is.

Case 3: two IPsec gateways (site-to-site VPN):

v6-only host ==== IPsec GW ==== (v6 and/or v4 connectivity) ==== IPsec 
GW ====== v4-only host

Here you can do NAT64 either on the v6 or the v4 side, assuming both are 
mixed networks, and we'd better recommend which one we prefer. IPsec 
here is definitely tunnel mode.

Case 4: dual stack host with v6-only connectivity. Yes this is perverse, 
but it may actually be common for a while.

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.

Thanks,
    Yaron

marcelo bagnulo wrote:

>> usually also support IPv4 in their stack during the transition 
>> period? I can imagine that constrained devices may want to drop IPv4 
>> support but it's hard to imagine devices that are willing to run 
>> IPsec but are too constrained to support IPv4.
>
> but in order to make it work, we not only need to have the v4 stack 
> but also the v4 address, which needs to be present in the IPSec SA in 
> the IPv4 only hosys (i.e. it is an IPv4 address that will be known by 
> the peer)
>
> scenario, then we simply need a tunnel between a dual stack host and 
> an IPv4 only host, which is not the application scenario for NAT64 imho
>
> In summary, i still think that IPSec tunnel case cannot be supported 
> in NAT64 scenario
>
>
>>
> Scanned by Check Point Total Security Gateway.
>

---

From: marcelo bagnulo <[email-masked]>
Date: Sun, 30 Mar 2008 11:07:19 +0200

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:
>
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?

> v6-only host ==== (v6-only connectivity) === (optional v4 network) 
> ==== IPsec Gateway ======== v4-only host
>
> We can use normal IPv6 IPsec in tunnel mode between the v6 host and 
> the gateway, followed by NAT64 on the v4 side.
>
but this doesn't involves the NAT64 box at all, i guess. So, even if 
this is a usefull case, this is transparent to the NAT64 box imho

> might need to require IPsec peers to allow this situation. Note that 
> in this sub-case, the encrypted traffic is never touched, only the UDP 
> encapsulation is.
>
Ok, so in this case we would have two NAT64 boxes, right?
One for inner header and other for the outer header, but the thing is 
that the inner header is performed AFTER the IPSec validation has been 
preformed. This may be interesting indeed. Still i think this is 
transparent to the NAT64 box right?

> Here you can do NAT64 either on the v6 or the v4 side, assuming both 
> are mixed networks, and we'd better recommend which one we prefer. 
> IPsec here is definitely tunnel mode.
>
so here we could have a NAT64 box between the two IPSec GW?
I mean is it possible that the IPSec GW are one v6 only and the other 
one IPv4 only?
> Case 4: dual stack host with v6-only connectivity. Yes this is 
> perverse, but it may actually be common for a while.
>
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

Thanks, marcelo

>> i may agree with the point that v6 only hosts will have an IPv4 
>> stack, but in order to make it work, we not only need to have the v4 
>> stack but also the v4 address, which needs to be present in the IPSec 
>> SA in the IPv4 only hosys (i.e. it is an IPv4 address that will be 
>> known by the peer)
>>
>>> possibly do everything that's needed to make IPsec work through 
>>> NAT64 the same way it today works through NAT44, with only minimal

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 30 Mar 2008 13:33:35 +0200

Hi Marcelo,

see my responses inline.

Thanks,
    Yaron

marcelo bagnulo wrote:
> 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.
> this is a usefull case, this is transparent to the NAT64 box imho
Yes, it should "just work".
>> in this sub-case, the encrypted traffic is never touched, only the 
>> UDP encapsulation is.
>>
I'm not sure. The left-hand side NAT64 box (between the v6 network and 
the v4 network) would need to convert IPv6 IPsec traffic, which is not 
specifically UDP or TCP into IPv4 traffic. This is not required in the 
problem statement, AFAICT.
>> v6-only host ==== IPsec GW ==== (v6 and/or v4 connectivity) ==== 
>> IPsec GW ====== v4-only host
>>
No (sorry I wasn't clear). You can have the box either to the left of 
the left-hand GW, or to the right of the right-hand GW. As for the hosts 
in case #1, you cannot have a v4-only GW talk to a v6-only GW.
>> creates an IPv4-IPsec tunnel with its peer, encapsulates it in UDP 
>> and sends it into the IPv6 network.
>>
> 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?
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.
>>>> period? I can imagine that constrained devices may want to drop 
>>>> IPv4 support but it's hard to imagine devices that are willing to 
>>>> run IPsec but are too constrained to support IPv4.
>>>
>>> stack but also the v4 address, which needs to be present in the 
>>> IPSec SA in the IPv4 only hosys (i.e. it is an IPv4 address that 
>>> will be known by the peer)
>>>
>>> So, if we assume that this is possible, then we are in the dual 
>>> stack scenario, then we simply need a tunnel between a dual stack 
>>> host and an IPv4 only host, which is not the application scenario 
>>> for NAT64 imho
>>>
>>>> It starts to look to me that the IPv6 side in a NAT64 scenario 
>>>> could possibly do everything that's needed to make IPsec work 
>>>> through NAT64 the same way it today works through NAT44, with only 
>>>> minimal cooperation from the NAT box.
>>>>

---

From: marcelo bagnulo <[email-masked]>
Date: Sun, 30 Mar 2008 23:12:50 +0200

below...

Yaron Sheffer escribió:
>> neither transport nor tunnel mode directly between them. That 
>> includes doing nor ESP nor AH nor IKE, is that correct?
just to make sure that i understand this
During the last meeting, people suggested that NAT64 should provide the 
same level  of IPSec support then regular v4NATs
That make sense to me, since in general, we can think that a v4 NAT 
would be as incompatible with IPSec as NAT64
AFAIU, regular NAT support for IPSec is defined in rfc3948
However, in RFC3948, there is support for IPSec in NATs both in 
transport mode and tunnel mode.
Tunnel mode seems differnet in the NATv4 case and the NAT64 case, so i 
understnad that it cannot work
However, do you think that the transport mode IPSec as described in 
rfc3948 cannot work in NAT64?

>>> left-hand side and IPsec traffic is then encapsulated in UDP/IPv4. 
>>> We might need to require IPsec peers to allow this situation. Note 
>>> that in this sub-case, the encrypted traffic is never touched, only 
>>> the UDP encapsulation is.
>>>
>> that the inner header is performed AFTER the IPSec validation has 
>> been preformed. This may be interesting indeed. Still i think this is 
right good point!
i think it makes sense to support this case, i will try to write 
something about this then

> the left-hand GW, or to the right of the right-hand GW. As for the 
> hosts in case #1, you cannot have a v4-only GW talk to a v6-only GW.
right
>>> 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.
>>>
>> 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?
> *inside* the IPsec tunnel. They are known as "Tunnel Inner Address (TIA)".
right, but my point is that you actually need to provision this addres, 
so there doesn't seem to be many advatages w.r.t. to a dual stack case 
(maybe with some tunnelling technique)

> 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.
right

thanks, marcelo

>>>>>> So IPSec tunnel mode, even if it is supported in v4NATs seems 
>>>>>> hard to support in NAT64, since each of the peers only speack one 
>>>> stack, but in order to make it work, we not only need to have the 
>>>> v4 stack but also the v4 address, which needs to be present in the 
>>>> So, the application scenario for NAT64 seems to imply that we 
>>>> cannot assume IPv4 address available in the ipv6 only host
>>>>
>>>> In summary, i still think that IPSec tunnel case cannot be 
>>>> supported in NAT64 scenario
>>>>
>>>>
>>>>>
>>>>>> yes, there seems to be one of such cases, which is IPSec 
>>>>>> transport mode the so called telecommuter scenario
>>>>>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 31 Mar 2008 11:27:51 +1300

Yaron,

> or IPsec unless it has access to the encryption keys, which would not

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

---

From: Hesham Soliman <[email-masked]>
Date: Mon, 31 Mar 2008 12:04:16 +1100

> During the last meeting, people suggested that NAT64 should provide  
> the same level  of IPSec support then regular v4NATs
> Tunnel mode seems differnet in the NATv4 case and the NAT64 case, so  
> i understnad that it cannot work

=> Only ESP and only if IKE can negotiate it properly using the v4  
addresses.

Hesham

---

From: Pekka Savola <[email-masked]>
Date: Mon, 31 Mar 2008 09:05:34 +0300 (EEST)

> enumerate the use cases, to clarify the situation a bit:

What about IPsec in Alain Durand's scenario:

v4-only host == NAT64 === v6-only network ==== NAT64 === v4-only network === v4-only host

I'm not sure how relevant this scenario is but if this wouldn't work 
it would mean that instead of double natting you'd have to do some 
tunneling (which might be for the best from another perspective).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 31 Mar 2008 14:59:57 +0200

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

>>> 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?

> (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.

---

From: "George Tsirtsis" <[email-masked]>
Date: Mon, 31 Mar 2008 13:20:48 +0000

>  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

---

From: "George Tsirtsis" <[email-masked]>
Date: Mon, 31 Mar 2008 13:23:24 +0000

I never show Alain's presentation first hand but I have heard about
it. As I think others have also commented, this scenario is best
served by tunnels. Use of translation in this case is really
distasteful to me.

Regards
George

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 31 Mar 2008 18:34:36 +0200

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

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 31 Mar 2008 18:43:11 +0200

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

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 1 Apr 2008 10:15:20 +1100

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:

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 01 Apr 2008 15:32:33 +1300

> understanding IPv4 addresses. What am I missing?

I don't think you're missing much, although I was suggesting that
by redesigning both IPsec and IKE we might find a mixed-mode
solution.

However, there is certainly an alternative to the whole NAT-PT
line of attack, which is to say that the solution is
a) all IPv6 hosts MUST be dual-stack
b) when connectivity to legacy IPv4 is required, and the host
is on an IPv6-only network, it MUST use an IPv4-in-IPv6 tunnel
c) which MAY be terminated by an IPv4 NAT, so that
the lack of IPv4 addresses is not an issue.

SOFTWIRE+BEHAVE

    Brian

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 1 Apr 2008 14:16:42 +1100

> the lack of IPv4 addresses is not an issue.

=> But that's effectvely where we are now. I take the above as a  
suggestion to scrap the NAT-PT work.
I'm at a bit of a loss as to why we scrapped NAT-PT and why we're  
doing a 180 on this decision.
Personally, I'm fine with doing the NAT-PT work and leaving it up to  
deployments to decide whether it's needed.
While I do agree that almost all hosts running v6 will also run v4, I  
don't think that every deployment will have enough IPv4
public or private addresses. So I think there may be a need for NAPT- 
PT in the market.

Hesham

>>>>> includes

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 01 Apr 2008 16:25:29 +1300

Hesham,

I agree that the market will decide in the end, and
personally I like the dual stack plus tunnel approach,
but we hear from the operational community that
IPv6-only nodes without dual stack need to be handled.
So, we are trying to deal with that.

However, I think we are pretty close to concluding
that a NAT64 solution can never support IPsec.

    Brian

On 2008-04-01 16:16, Hesham Soliman wrote:
> I'm at a bit of a loss as to why we scrapped NAT-PT and why we're doing
> a 180 on this decision.
> public or private addresses. So I think there may be a need for NAPT-PT
> in the market.
> 
> Hesham
> 
>>
>>
>> SOFTWIRE+BEHAVE
>>
>>    Brian
>>>
>>>
>>> Thanks,
>>>
>>>   Yaron
>>>
>>>
>>> Brian E Carpenter wrote:
>>>
>>>> Yaron,
>>>>

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 1 Apr 2008 14:44:37 +1100

> that a NAT64 solution can never support IPsec.

=> Agreed.

Hesham