Why anyone in their right mind would like to use NAT64

classic Classic list List threaded Threaded
47 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Why anyone in their right mind would like to use NAT64

Stuart Henderson
On 2012-10-25, Simon Perreault <[hidden email]> wrote:
> Le 2012-10-25 00:20, Constantine A. Murenin a écrit :
>> No dual-stacking is
>> provided; in their slides from [0], T-Mobile USA claims that IPv6-only
>> with NAT64/DNS64 is cheaper than dual-stack with NAT44.
>
> Yes. I forgot to mention another reason why the 3GPP folks like NAT64:
> most 3GPP equipment vendors charge ISPs by the number of "PDP contexts".

AIUI the second context also affects battery use on mobile devices.

> Currently deployed equipment can not do dual-stack PDP contexts.

The dual-stack contexts were added in 3gpp rel-8 and improved in
rel-9 (from 2008/2009), so I guess it might take another few years
before equipment supporting this gets widely deployed and they get
the time between crashes down to an acceptable amount ;)

Reply | Threaded
Open this post in threaded view
|

Re: Why anyone in their right mind would like to use NAT64

Otto Moerbeek
On Thu, Oct 25, 2012 at 02:23:06PM +0000, Stuart Henderson wrote:

> On 2012-10-25, Simon Perreault <[hidden email]> wrote:
> > Le 2012-10-25 00:20, Constantine A. Murenin a ??crit :
> >> No dual-stacking is
> >> provided; in their slides from [0], T-Mobile USA claims that IPv6-only
> >> with NAT64/DNS64 is cheaper than dual-stack with NAT44.
> >
> > Yes. I forgot to mention another reason why the 3GPP folks like NAT64:
> > most 3GPP equipment vendors charge ISPs by the number of "PDP contexts".
>
> AIUI the second context also affects battery use on mobile devices.
>
> > Currently deployed equipment can not do dual-stack PDP contexts.
>
> The dual-stack contexts were added in 3gpp rel-8 and improved in
> rel-9 (from 2008/2009), so I guess it might take another few years
> before equipment supporting this gets widely deployed and they get
> the time between crashes down to an acceptable amount ;)

down? I hope you mean up ;-)

Reply | Threaded
Open this post in threaded view
|

Re: Why anyone in their right mind would like to use NAT64

Mark Felder-4
In reply to this post by Simon Perreault-2
On Wed, 24 Oct 2012 15:33:55 -0400
Simon Perreault <[hidden email]> wrote:

> I'm going to wait a long time for a firmware update that makes my
> IPv4-only printer speak IPv6.

My brother wifi printer from... 5 years ago?? supports ipv6. Sometimes I enable it and publish it in IRC and see how many wonderful printouts I get...

Reply | Threaded
Open this post in threaded view
|

Re: Why anyone in their right mind would like to use NAT64

Martin Hein
In reply to this post by Claudio Jeker
On Wed, 24 Oct 2012 22:16:04 +0200
Claudio Jeker <[hidden email]> wrote:
> Just as an example. A few weeks ago it was a lot easier to get one of
> the last IPv4 PI address blocks at RIPE than getting a PI IPv6 block.
> Since the first one has no strings attached (apart from having an AS
> number) and the second one comes with a big ball of wool of extra
> rules that need to be ensured and ensured and pretty please and yes
> please I would like PI space.

RIPE NCC policy has one blocking rule:

* You *must* multi home. as in you must have a AS number.
 
So if you have an AS number and you use it, like you said you would when
you applied, you will get IPv6 PI space.

As a LIR we do IPv6 PI requests for end users and RIPE NCC do not make
troubles about it. If you tell stories in your requests they starts asking
annoying questions.

/Martin

btw, when we run out of v4 space and cant dual stack anymore we will
start to use NAT64/DNS64. But hopefully the rest out the Internet has
changed to v6 only before we run out.

Reply | Threaded
Open this post in threaded view
|

Re: Why anyone in their right mind would like to use NAT64

Henning Brauer
In reply to this post by Daniel Ouellet
sigh. another essay without actual content.

* Daniel Ouellet <[hidden email]> [2012-10-24 20:00]:
> NAT always makes connectivity less efficient

yeah, rrrrright.

> NAT was sadly a quick way to setup security

b***s***.

> NAT needs to process every packets

opposed to the !NAT case, where a router doesn't have to "process"
every packet. rrright.

> changed the header both in incoming and outgoing traffic

opposed to the !NAT case, rrrrrrrrright.

> and as bandwidth keep increasing only
> make the totally not optimize NAT table getting bigger

parser error

> as more
> traffic is present and increase jitter, latency, etc. Much more
> powerful router needs to be used and many of the sadly loved
> firewall appliance by some admin like the SonicWall and the like
> running out of power on intensive UDP traffic and do not allow the
> end users to actually get the benefit of their increase line
> capacity that are more common these days!

one thing is clear: you have no clue what you are talking about.

once stateful firewalling is in place, the cost of NAT is neglible.

> IN IPv6, the smallest assigned to remote site is so big anyway and
> based on the RFC recommendation to provide a /48 to remote site and
> even a /56 to a single house, how could anyone possibly think he/she
> would even run of IP's and need NAT64?

there are gazillion more (very very valid) use cases for NAT than to
preserve IP addresses.

> Isn't it just a side effect of a sadly miss guided use of NAT in

the only "miss guided" person here is you.

--
Henning Brauer, [hidden email], [hidden email]
BS Web Services, http://bsws.de, Full-Service ISP
Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed
Henning Brauer Consulting, http://henningbrauer.com/

Reply | Threaded
Open this post in threaded view
|

Re: Why anyone in their right mind would like to use NAT64

Henning Brauer
In reply to this post by Jussi Peltola
* Jussi Peltola <[hidden email]> [2012-10-24 21:37]:
> This is something that can only be fixed by getting rid of the
> assumption about non-changing host addresses.

what a brilliant design. instead of fixing a networking problem at the
networking layer change all the layers above, up to and including the
application layer.

but NAT is bad, right.

> NATs tend to break my idle SSH sessions

that is just one more of the lies spread all over the place.
NAT doesn't have ANYTHING to do with that really.
what you are seeing are broken devices throwing away state they must
not. yes, they are common. and NAT is common. but blaming one on the
other is still just wrong.

> Do your ssh sessions stay up if one of your upstreams starts blackholing
> but still announces you a full table of routes?

now that is even more ridulous. the problem is blackholing, the
solution is to not blackhole, not to apply gazillions of stupid
workarounds.

and guess what: in practice, accidental blackholing is extremely rare.

--
Henning Brauer, [hidden email], [hidden email]
BS Web Services, http://bsws.de, Full-Service ISP
Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed
Henning Brauer Consulting, http://henningbrauer.com/

Reply | Threaded
Open this post in threaded view
|

Re: Why anyone in their right mind would like to use NAT64

Henning Brauer
In reply to this post by Otto Moerbeek
* Otto Moerbeek <[hidden email]> [2012-10-25 16:34]:
> On Thu, Oct 25, 2012 at 02:23:06PM +0000, Stuart Henderson wrote:
> > and they get the time between crashes down to an acceptable amount
> down? I hope you mean up ;-)

we're talking about the industry that has gazillions of gsm access
points installed with baseband controllers that crash more than once a
minute. and instead of fixing their broken software they apply
workaround hacks, and since these are of the same quality they apply
another layer of workaround hacks, and ...

and now THESE PEOPLE apply THEIR APPROACH to the internet, and we're
supposed to implement their workaround hacks so that they can continue
to deploy shit? brilliant approach.

--
Henning Brauer, [hidden email], [hidden email]
BS Web Services, http://bsws.de, Full-Service ISP
Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed
Henning Brauer Consulting, http://henningbrauer.com/

123