[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Tunnels vs translation, was: Re: A slightly more detailed analysis Re: NAT64 and IPsec support
On 2 apr 2008, at 17:14, George Tsirtsis wrote:
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.
That's a reasonable position. However, if this happens in IPsec tunnel
mode, it's still first and foremost an IPsec problem.
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.
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.