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

["George Tsirtsis" <tsirtsis@googlemail.com>]

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 <iljitsch@muada.com> wrote:
> 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.
>