NAT66 Experimental Draft - RFC6296

Cameron Byrne cb.list6 at gmail.com
Sat Jul 23 21:31:07 CEST 2011


On Jul 23, 2011 12:18 PM, "Olipro" <olipro at 8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa>
wrote:
>
> 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.
>

Wow. That's too bad.

> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20110723/f03e14c5/attachment.htm>


More information about the ipv6-ops mailing list