Hi Christian, Christian Huitema wrote: >> From: Eric Klein, Sunday, February 01, 2009 7:38 AM >> >> The original threads that lead to this list being created all came >> down to the basic Boolean question: Do we in the IETF want to allow >> NAT66 at all in IPv6 even though IPv6 was originally designed not >> to allow it? > > Reality check. The IETF has no protocol police, let alone network > police. The IETF cannot allow or disallow things, at least not > through an IETF pronouncement. The IETF only has three choices:
That's correct. > 1) The Pilatus option: the IETF officially says that it does not like > NAT, and washes its hand from the outcome. > > 2) The Attila-the-Hun option: the IETF dislikes NAT so much that it > starts engineering protocols that absolutely break if someone dare > deploy NAT. > > 3) The Munich option: the IETF recognizes that the evil won't be > stopped, so dirty its hands and tries a compromise. My problems with option 3) are: * people will start to use NAT66 (once available), because they are just used to have a NAT for IPv4 (and probably additionally confuse it as a security measure). This effect should not be underestimated, no matter what health warnings the IETF puts in RFCs, which are probably read by the implementers, but not by the users/"operators" then. If there is no NAT for IPv6, people need to think about why this may be case and look for other solutions. * even though NAT66 does some clever tricks to cause less pain for the address translation process itself, the problem with IP addresses somewhere in the payload remain. Thus, NAT66 will be an obstacle for future applications (otherwise every application must be made NAT-aware, use STUN etc.) Regards, Roland _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
