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.
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.
* 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?
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.
--
james woodyatt <[email protected]>
member of technical staff, communications engineering
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
