Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: nsp: ipv6

NAT66 Experimental Draft - RFC6296

 

 

nsp ipv6 RSS feed   Index | Next | Previous | View Threaded


olipro at 8

Jul 23, 2011, 8:59 AM

Post #1 of 6 (1039 views)
Permalink
NAT66 Experimental Draft - RFC6296

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.


olipro at 8

Jul 23, 2011, 10:40 AM

Post #2 of 6 (989 views)
Permalink
Re: NAT66 Experimental Draft - RFC6296 [In reply to]

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.


ben at bjencks

Jul 23, 2011, 12:05 PM

Post #3 of 6 (997 views)
Permalink
Re: NAT66 Experimental Draft - RFC6296 [In reply to]

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


cb.list6 at gmail

Jul 23, 2011, 12:31 PM

Post #4 of 6 (984 views)
Permalink
Re: NAT66 Experimental Draft - RFC6296 [In reply to]

On Jul 23, 2011 12:18 PM, "Olipro" <olipro [at] 8>
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.


aservin at lacnic

Jul 26, 2011, 10:48 AM

Post #5 of 6 (959 views)
Permalink
Re: NAT66 Experimental Draft - RFC6296 [In reply to]

We do that.

http://www.lacnic.net/en/politicas/manual5.html

4.5.4. Direct Assignments to End Sites

-as

On 23 Jul 2011, at 13:40, Olipro wrote:

> 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.


spz at serpens

Jul 30, 2011, 12:26 AM

Post #6 of 6 (955 views)
Permalink
Re: NAT66 Experimental Draft - RFC6296 [In reply to]

Thus wrote Olipro (olipro [at] 8):

> So, it would appear that things on the NAT66 front have progressed from the
> IETF over to RFC status.

Note that RFC6296 is strictly algorithmic prefix translation, NPT66.

> 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.

NPT66 tells you how to calculate the translation, it contains the formula:

--- cite ---
o The internal prefix is overwritten with the external prefix, in
effect subtracting the difference between the two checksums (the
adjustment) from the pseudo-header's checksum, and

o A 16-bit word of the address has the adjustment added
to it using one's complement arithmetic. If the result is
0xFFFF, it is overwritten as zero. The choice of word is
as specified in Sections 3.4 or 3.5 as appropriate.
--- /cite ---

This determines which address you must translate to given an inside and
outside prefix, 100% deterministic and reversible given the same
information.

Of course that will stop nobody from doing something else entirely, but
that's as little RFC6296's fault as was translating the SMTP dialog to
German by Sinix the then SMTP RFCs fault.

regards,
spz
--
spz [at] serpens (S.P.Zeidler)

nsp ipv6 RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.