NAT66 Experimental Draft - RFC6296

[Olipro]

On Saturday 23 Jul 2011 20:05:53 you wrote:
> 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

True, although as it stands it can become dangerous; as it stands there's 
already a certain Finnish operator who is giving clients unrouted /64 subnets 
and informing them to "use NAT" if they want to have connectivity for multiple 
clients on their network (actually the correct solution is proxy_ndp but these 
guys are evidently braindead) - the privilege of a routed /64 comes at 
something like €24.95 a month.

Ultimately I think it'll come down to what sort of "agenda" (if any) the RIRs 
push with regards to allocating to end users; we all know there's RFCs that 
basically cover this down to a very fine point, but some people just don't 
listen.