On Apr 1, 2009, at 6:38 AM, Margaret Wasserman wrote:
One problem with this name is that a NAT66 device is _not_ stateless. It requires configured/static state to function -- at least the two prefixes between which it is translating.
In the work in Behave, we have very carefully defined "state" to mean "dynamic state" as opposed to "configuration". RFC 2765, Stateless Address Translation, has configuration as well (at minimum it has to be turned on). I think Remi is using the same line of reasoning here. Yes, it uses configuration (of an inside and an outside prefix), but there is no per-flow or per-end-system state maintained. As a result, if I want to load-share across two identically-configured NAT66 devices, I don't need to coordinate - they both have the information they need to come up with the same result.
In my experience, the terms NAT44, NAT64, NAT46 and NAT66 are the _names_ of specific IETF proposals. The terms IPv4 NAT and IPv6 NAT are used to generically identify IPv4-to-IPv4 NAT devices and IPv6- to-IPv6 NAT devices, respectively.
I agree, and at the same time I am aware that people use these terms in a generic sense. In the behave context, I am trying to replace both the names IVI and NAT46 (which are names of specific proposals) with reference to IPv4/IPv6 translation, and am getting pushback that "that is generically called NAT46", which happens to be the name of one document in a four document set. It is very confusing.
I agree that we are better talking about "IPv4/IPv4 NAT", "IPv6/IPv6 something", and "IPv4/IPv6 translation" as the generic terms.
That said, I think Remi has made a good suggestion here. Calling it Stateless Address Translation makes sense, I think.
_______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
