NAT66 Experimental Draft - RFC6296

[Ben Jencks]

On Jul 23, 2011, at 11:59 AM, Olipro wrote:

> Greetings to all,
> 
> So, it would appear that things on the NAT66 front have progressed from the 
> IETF over to RFC status.
> 
> Whilst NAT66 is certainly something that could prove invaluable if you wish to 
> setup a network without having to worry about renumbering problems down the 
> line, it does also raise the issue of making a number of daft things possible 
> - namely, whilst the RFC does state that the NAT/NPT itself will only perform 
> 1:1 mappings, it doesn't make any requirement that you must not use it with 
> connection tracking or anything else that could run atop the translator and 
> affect exactly what addresses it translates to.
> 
> As a result, I can foresee the possibility of using stateful connection 
> tracking to do something along the lines of multiplexing a global unicast 
> address to multiple clients on the internal side of the network by giving them 
> all separate ULA addresses and then setting up conntrack rules to affect the 
> translations that will occur, which sounds to me like a recipe for someone, 
> somewhere thinking he can get away with a single global unicast subnet of the 
> minimum required size and stick everyone he serves on ULA addresses... Or 
> maybe I'm just being too pessimistic.

Sometimes you just have to give people enough rope to hang themselves. As long as it's only semi-clued "security"-conscious enterprise operators doing it, it doesn't really hurt anyone but themselves. I'd only worry about it if it becomes widespread enough that software developers feel the need to start writing workarounds (STUN, etc.) into their software.

-Ben