<p><br>
On Jul 23, 2011 12:18 PM, "Olipro" <olipro@8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa> wrote:<br>
><br>
> On Saturday 23 Jul 2011 20:05:53 you wrote:<br>
> > On Jul 23, 2011, at 11:59 AM, Olipro wrote:<br>
> > > Greetings to all,<br>
> > ><br>
> > > So, it would appear that things on the NAT66 front have progressed from<br>
> > > the IETF over to RFC status.<br>
> > ><br>
> > > Whilst NAT66 is certainly something that could prove invaluable if you<br>
> > > wish to setup a network without having to worry about renumbering<br>
> > > problems down the line, it does also raise the issue of making a number<br>
> > > of daft things possible - namely, whilst the RFC does state that the<br>
> > > NAT/NPT itself will only perform 1:1 mappings, it doesn't make any<br>
> > > requirement that you must not use it with connection tracking or<br>
> > > anything else that could run atop the translator and affect exactly what<br>
> > > addresses it translates to.<br>
> > ><br>
> > > As a result, I can foresee the possibility of using stateful connection<br>
> > > tracking to do something along the lines of multiplexing a global unicast<br>
> > > address to multiple clients on the internal side of the network by giving<br>
> > > them all separate ULA addresses and then setting up conntrack rules to<br>
> > > affect the translations that will occur, which sounds to me like a<br>
> > > recipe for someone, somewhere thinking he can get away with a single<br>
> > > global unicast subnet of the minimum required size and stick everyone he<br>
> > > serves on ULA addresses... Or maybe I'm just being too pessimistic.<br>
> ><br>
> > Sometimes you just have to give people enough rope to hang themselves. As<br>
> > long as it's only semi-clued "security"-conscious enterprise operators<br>
> > doing it, it doesn't really hurt anyone but themselves. I'd only worry<br>
> > about it if it becomes widespread enough that software developers feel the<br>
> > need to start writing workarounds (STUN, etc.) into their software.<br>
> ><br>
> > -Ben<br>
><br>
> True, although as it stands it can become dangerous; as it stands there's<br>
> already a certain Finnish operator who is giving clients unrouted /64 subnets<br>
> and informing them to "use NAT" if they want to have connectivity for multiple<br>
> clients on their network (actually the correct solution is proxy_ndp but these<br>
> guys are evidently braindead) - the privilege of a routed /64 comes at<br>
> something like €24.95 a month.<br>
></p>
<p>Wow. That's too bad.<br></p>
<p>> Ultimately I think it'll come down to what sort of "agenda" (if any) the RIRs<br>
> push with regards to allocating to end users; we all know there's RFCs that<br>
> basically cover this down to a very fine point, but some people just don't<br>
> listen.<br>
</p>