If NAPT66 creeps into the picture (with a P) - we might be able to implement a SAF mechanism (or its equivalent) by allowing hosts to query the NAPT66 box about its bindings through some protocol. If hosts knew what their external binding was, they would be able to reverse the translation, restoring transparency - however, this may not be as straight-forward as it is with the mechanism proposed for NAT66 (referring to Margaret's draft) - especially if the host has to reverse ALG's.
- Wes -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of james woodyatt Sent: Friday, April 03, 2009 4: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. -- james woodyatt <[email protected]> member of technical staff, communications engineering _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66 _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
