Subject: Re: A slightly more detailed analysis Re: NAT64 and IPsec support

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 2 Apr 2008 17:01:15 +0200

On 1 apr 2008, at 17:39, marcelo bagnulo wrote:

>>> > I think this conclusively renders "IPSEC over NAT64 for  
>>> unmodified end
>>> > nodes" unrealistic. Any disagrees with that?

Right.

>>> So i am planning to NOT to include a basic requirement  abou any  
>>> form of
>>> IPSec support wihtout endpoint support, ok?

I agree with that. We can encourage translator builders to look at  
RFCs 3947 and 3948 (IKE and ESP through NAT, respectively) so they can  
be sure they don't break those, but apart from that it looks like the  
translator isn't in the position to help or hurt IPsec support.

>> GT> No, Marcelo, what I describe above applies to BOTH!. Remember  
>> that
>> when you do UDP/IP based NAT traversal, IPSEC applies to whatever you
>> send OVER the unprotected UDP/IP tunnel. So, on top of UDP/IP you can
>> run either  transport or tunnel mode IPSEC. Both have problems IMO.

> right, i was confused about this, i agree with you

Hm, I think there are several ways to make it work, in addition to  
countless ways that can't work. Two examples of the former:

A -- T -- B

A is a host with an IPv6/IPv4 stack but only IPv6 connectivity
T is the translator
B is an IPv4 host

In this case, A pretty much has to act like it has IPv4-behind-NAT and  
present an RFC 1918 address in IKE towards B, and then subsequently  
generate segments (transport mode) or packets (tunnel mode) that make  
sense as IPv4, then put those in ESP, UDP and IPv6 and send them to B  
through the translator. B doesn't have to know about any of this.

A -- T --S -- U -- B

A is a host with an IPv6/IPv4 stack but only IPv6 connectivity
T is the translator in the service provider network
S is a dual stack security gateway that terminates IPsec
U is a translator part of B's network
B is an IPv4 host

In this scenario A can negotiate inner IPv6 headers with S but this  
means both S and A must be updated. The inner packets are then  
translated again for consumption by B.

>>> IPSec MUST be supported but modifications to the endpoints may be  
>>> needed.

No, MUST is too strong.

> So my question is: is is possible to support IPSec with only  
> modifying the v6 side and keeping the v4 side untouched? from you  
> description above it seems to me that it would be possible (i guess  
> that the v4 side needs to implement rfc3948, right?)

I think so, yes. See above.

---

From: "George Tsirtsis" <[email-masked]>
Date: Wed, 2 Apr 2008 16:14:04 +0100

Hi Iljitsch,

You seem to be talking about how to enable IPv4 communications for
Dual Stack nodes that happen to be connected to IPv6-only networks. To
me this is NOT an NAT-PT problem. It is a tunneling problem.

The scenarios you describe below require a box that can receive an
IPv6 tunnel from one side and forward the encapsulated IPv4 traffic on
the other side. This could also be combined with a v4NAT for efficient
use of IPv4 addresses, but in now way this requires protocol
translation.

                           IPv4overIPv6
         IPv4
IPv6/IPv4 Node ============TunnelEndPoint+v4NAT-----------------IPv4 only node

Do not get me wrong, I think this is a good thing to enable, and such
a function would make sense to be collocated in a NAT64 box, but it
has nothing to do with an IPv6 to IPv4 protocol translation as such.

Am I missing something? Wouldn't such a technique be best
documented/defined in a separate RFC? After all, many mechanisms for
creating such tunnels were defined in NGTRANS WG...some of which could
be re-usable for this.

Best regards
George

On Wed, Apr 2, 2008 at 4:01 PM, Iljitsch van Beijnum <[email-masked]> wrote:
> > > > > I think this conclusively renders "IPSEC over NAT64 for unmodified
> end
> > > > So i am planning to NOT to include a basic requirement  abou any form
> of
>  I agree with that. We can encourage translator builders to look at RFCs
> 3947 and 3948 (IKE and ESP through NAT, respectively) so they can be sure
> they don't break those, but apart from that it looks like the translator
> isn't in the position to help or hurt IPsec support.
>
>
>
> >
> > > GT> No, Marcelo, what I describe above applies to BOTH!. Remember that
> present an RFC 1918 address in IKE towards B, and then subsequently generate
> segments (transport mode) or packets (tunnel mode) that make sense as IPv4,
> then put those in ESP, UDP and IPv6 and send them to B through the
> translator. B doesn't have to know about any of this.
>
>  A -- T --S -- U -- B
>
>  In this scenario A can negotiate inner IPv6 headers with S but this means
> both S and A must be updated. The inner packets are then translated again
> for consumption by B.
>
>
>
> >
> > >
> > So my question is: is is possible to support IPSec with only modifying the
> v6 side and keeping the v4 side untouched? from you description above it
> seems to me that it would be possible (i guess that the v4 side needs to
> implement rfc3948, right?)
> >
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 3 Apr 2008 13:35:21 +0200

> me this is NOT an NAT-PT problem. It is a tunneling problem.

That's a reasonable position. However, if this happens in IPsec tunnel  
mode, it's still first and foremost an IPsec problem.

> creating such tunnels were defined in NGTRANS WG...some of which could

I don't think IPsec tunnels are very much interchangable with other  
types of tunnels. Also, I don't think there is a need to document  
anything. If an implementer wants to make this work, they simply need  
to make things such that the IPv4 side sees standard IPv4-through-NAT  
IKE and ESP.

As for the more general issue of whether to use tunnels or translation:

Tunnels have the advantage that the IPv6 host really knows that it's  
actually talking to an IPv4 destination and no header fields can be  
"lost in translation". However, there are numerous disadvantages.  
First of all, it's not transparent. Hosts need to be modified to work  
with tunnels, or a separate device must be installed. Then, it's  
necessary to discover the remote tunnel endpoint, and addresses must  
be configured for both sides. With translation on the other hand, any  
type of communication that doesn't need to know whether it's talking  
to an IPv4 or IPv6 destination can simply work without any changes.

Interestingly, if you do NAT you do translation anyway. So tunneling +  
NAT is pretty much always more work than NAT-PT. As such, I don't  
think the combination tunneling + NAT is a good one, although  
tunneling with a public IPv4 address is a good solution in cases where  
a public IPv4 address is required. Note however, that all the state  
that's necessary for a tunnel scales at O(tunnel users), while the  
state in a NAT-PT translator scales O(sessions). The latter is almost  
certainly a larger number, but it has the advantage that state only  
needs to be maintained as long as a session is active. If we move  
towards a situation where there are many devices per end-user, having  
to keep tunnel state for each of them although they may only be active  
for minutes per day becomes an issue.

As for the v4v6v4 issue: if we have a good solution for the v6v4 part,  
this is fairly trivial, we just need to do one-to-one SIIT between v4  
and v6 and route packets towards the translator. Since the v4v6 SIIT  
step is stateless you only take a single NAT hit and create very  
little extra state. If, on the other hand, you tunnel a private v4  
network over v6 to a NAT then you run out of private v4 space  
relatively quickly, pretty much retaining most of the IPv4 address  
management issues even though you don't use public IPv4 addresses.

---

From: Rémi Després <[email-masked]>
Date: Mon, 21 Apr 2008 11:00:11 +0200

George Tsirtsis wrote :

> IPv6 tunnel from one side and forward the encapsulated IPv4 traffic 
> on the other side. This could also be combined with a v4NAT for 
> efficient use of IPv4 addresses, but in now way this requires 
> protocol translation.

> IPv6/IPv4 Node ======= TunnelEndPoint+v4NAT -------- IPv4 only node

A configuration with similar properties is covered in:
http://www.ietf.org/internet-drafts/draft-despres-v6ops-apbp-00.txt

The configuration, where APBP means Address-port-borrowing-protocol,
looks like:

Dual-stack node+APBP ======= APBP ===== IPv4-only node

- No NAT is needed (E2E transport connections are transparent IPv4
between applications)
- TUNNELS v4 over v6 are etablished "per connection", with a request to
an anycast address to find each APBP tunnel endpoint.

Another important configuration is:

IPv4-only node ------- v4NAT+APBP ======= APBP ------- IPv4 node

> ... such a function would make sense to be collocated in a NAT64 box,
>  but it has nothing to do with an IPv6 to IPv4 protocol translation 
> as such.
Right.
With APBP, the v4NAT+APBP function also can be collocated in a NAT64 box.
The need for NAT64 is however mitigated if APBP is available.

(Comments most welcome.)

Regards.

Rémi