> -----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? > > 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). 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. -Dave _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
