> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of james woodyatt > Sent: Friday, April 03, 2009 1:45 PM > To: NAT66 HappyFunBall > Subject: [nat66] RSIP and NAT66 > > everyone-- > > Would the authors of the NAT66 draft consider adding a requirement for > NAT66 gateways to comprise the combination of the translator function > with the IPv6-relevant functions of Realm-specific IP servers for > symmetric NAT, c.f. RFCs 3102 and 3103? (I don't see an immediate > need to worry about the functions defined in RFC 3104 as long as > address amplification can remain off the table as a goal for any IPv6/ > NAT standard.) > > I think requiring RSIP servers in the NAT66 gateway would address Dave > Thaler's argument about Source Address Finding (SAF) as presented in > draft-thaler-ipv6-saf, and I'm inviting the authors to respond with > comments. I'd be a lot less wiggy about NAT66 if it looked like RSIP > (or its moral equivalent) might finally see the light of day.
Hi James, I've now had a chance to read about RSIP and also talk to Gabriel Montenegro, one of its authors, and can answer the question you asked me during the meeting (what's the difference between the SAF model and RSIP). 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). 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). * 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. * 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. Gabriel also pointed me to http://tools.ietf.org/html/draft-montenegro-aatn-nar which was an RSIP precedessor that does allow translation (and hence may fall into the SAF category but I still need to read it). -Dave _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
