Dave Thaler - le (m/j/a) 4/4/09 4:20 AM:
-----Original Message-----
From: james woodyatt [mailto:[email protected]]
Sent: Friday, April 03, 2009 4:01 PM
To: Dave Thaler
Cc: NAT66 HappyFunBall
Subject: Re: [nat66] RSIP and NAT66
On Apr 3, 2009, at 14:56, Dave Thaler wrote:
RSIP is quite different from SAF, although it attempts to achieve
end-to-end transparency as well. In the taxonomy of solution classes
in draft-iab-ipv6-nat, RSIP is in the second class (tunneling),
whereas
NAT66 and hence SAF fall into the third class (translation).
My understanding of SAF, from the presentation you gave at the 6AI
session at IETF 74, is that it too is a tunneling solution-- just that
the tunnel is compressed on the wire. From the perspective of an
application in a SAF-enabled host, it looks like there is a tunnel
interface with an address assigned from the exterior realm. Transport
endpoints on the host think they are bound to their exterior realm
address mapped by the NAT66 gateway.
That's not correct. The SAF model is a translate-and-detranslate model.
So the differences between RSIP and NAT66+SAF are:
* RSIP uses tunneling, whereas NAT66+SAF use translation. Tunneling
introduces MTU issues, and has greater incentive issues since you
get nothing until you update both hosts and gateways, whereas
with translation you get something when you only deploy a gateway
(the slide I showed with some happy apps and some unhappy apps).
I'll grant that RSIP, as it was published, did not compress the
tunnel, and so it would have the MTU issue that people are worrying
about because of the inner/outer headers. If a compliant NAT66
gateway were also to comprise an RSIP-derived service that optionally
permitted the tunnel to be compressed as you described in your
presentation, then that would seem to cover all the cases, wouldn't
it? Hosts and/or networks could decide whether they want compressed
or uncompressed tunnels.
The point I'm trying to raise is that we should insist that no NAT66
gateways be deployed unless they already have the upgrade path for
hosts to permit the restoration of transparency. Whether the tunnels
or compressed or not is of only secondary interest to me at this point.
The SAF model is an illustration that there's an upgrade path
without having to change the NAT66 device, but you do have to change
the host (just not at the same time).
* RSIP requires hosts to know the IP address of the gateway,
whereas NAT66+SAF do not. As such, failover is better with
NAT66+SAF
since the gateway is stateless and routing can just reroute traffic
to the working exit/entry point.
Isn't Christian Huitema's point about multi-homing relevant here?
Any reference where the point is described?
In any event, if RSIP is extended to support tunnel compression, then
hosts would be freed from the requirement to know the interior realm
address of any particular NAT66 gateway; they could just send to the
exterior realm destination address and rely on the network to forward
traffic accordingly. Hosts would still be at the mercy of the network
in the case of Christian's multi-homing scenario.
* RSIP requires (and specifies) a signaling protocol between the
host and the gateway. A SAF mechanism may or may not have such
a protocol. Minimally, all that's required is that it get the
inner/outer prefix if you're using NAT66 (or equivalent if you're
using another IPv6 NAT mechanism). It could get these from
some internal entity (like a DHCPv6 server), from the NAT itself
via a signaling protocol, or from an external entity more like
STUN/Teredo use. This flexibility is important to note since
if someone deploys a NAT66 today and then wants to do a SAF
mechanism, it means there are ways to do so that don't entail
upgrading the NAT66 device.
I'd like to see NAT66 service, if we're going to standardize one,
start at day one with a SAF mechanism, and I think that RSIP (or
perhaps its predecessor, NAR, if we want to ignore Christian's point
about multi-homing) could be a fine starting point for documents to
adopt in any working group process we might contemplate starting.
If we have the liberty of starting at day one with a SAF mechanism,
I would agree. However, if "vendors already have NAT66" but not
SAF then I don't know if we have that liberty (again I hope we do,
and I agree with you). NAR is perhaps one SAF mechanism worth
evaluation, and I expect there are others as well (Remi stated he
believes SAM is another SAF mechanism, for example, and I'm sure
the possibilities don't stop there).
Let me confirm here that SAM is intended in particular to restore e2e
transparency, and to support multihoming in an ingress-filtering
compatible way. It uses for this encapsulation with a stateless address
mapping. It doesn't need a new protocol.
Having comments from someone having taken the time to read the posted
draft-despres-sam-02 would be highly appreciated.
In my understanding, SAF does need encapsulation in the multihoming
case. The question is then whether, to keep things simpler,
encapsulation should be authorized also in the single-homing case, or
whether it should be forbidden wherever it is feasible to avoid it. (The
first option seems preferable for me. "Simplicity is the ultimate
sophistication" - Leonardo da Vinci)
Last point: encapsulation can advantageously be used as a sign that e2e
transparency is expected, even in the single-homing case. Conversely,
absence of encapsulation can be used as an indication that address
modification is accepted or expected: accepted if due to an inability to
do it, which ensures backward compatibility with legacy IPv6 hosts;
expected if due to a conscious desire for address modification, e.g. for
some privacy reason.
However your main point, I gather, is that if we publish NAT66 as
an RFC, we should really simultaneously publish some SAF mechanism.
I am of the same opinion here.
Going further, why to exclude publishing an e2e transparent solution
before a non-transparent one, if this is possible. (Of course, it can
only be possible if tried :-))
RD
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
