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

Barbier, Jason
On Wed, Oct 24, 2012 at 12:33 PM, Simon Perreault
<[hidden email]>wrote:

> Le 2012-10-24 15:29, Barbier, Jason a écrit :
>
>  Well expanding on the address space and numbering issue, that would be a
>> valid use for NAT but I honestly think it would be better to actually try
>> and fix that before trying to put a hack over the top of it.
>>
>
> I'm going to wait a long time for a firmware update that makes my
> IPv4-only printer speak IPv6.
>
> Simon


Well man there are several stable implementations of 4 to 6 and 6 to 4
bridges.


--
Jason Barbier

Pro Patria Vigilans

Reply | Threaded
Open this post in threaded view
|

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

Jussi Peltola
In reply to this post by Theo de Raadt
On Wed, Oct 24, 2012 at 01:28:38PM -0600, Theo de Raadt wrote:
> Basically to make IPv6 pseudo-"multihoming" work like IPv4
> multihoming, ssh and sshd need to be modified that they can handle a
> network break, and re-connect using another address.
 
I fail to see what any of this has to do with address families. You can
multihome in every way possible in v4 with v6.

The DFZ will not scale to everyone's iPad having their own prefix,
sending an update each time they hop on to another network.

Reply | Threaded
Open this post in threaded view
|

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

Simon Perreault-2
In reply to this post by Barbier, Jason
Le 2012-10-24 15:38, Barbier, Jason a écrit :
>> I'm going to wait a long time for a firmware update that makes my
>> IPv4-only printer speak IPv6.
>
> Well man there are several stable implementations of 4 to 6 and 6 to 4
> bridges.

I don't know what kind of "bridges" you're talking about, but I'll
assume that pf's NAT64 implementation is one of them.

Simon

Reply | Threaded
Open this post in threaded view
|

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

Theo de Raadt
In reply to this post by Jussi Peltola
> On Wed, Oct 24, 2012 at 01:21:33PM -0600, Theo de Raadt wrote:
> > What happens if one of your links goes down for a day?
> >
> > Do all your ssh sessions to everywhere in the world stay up?
> >
> > The internet has non-transient traffic, too.
>  
> No, I will have to re-start some of them. This is something that can
> only be fixed by getting rid of the assumption about non-changing host
> addresses.

Luckily that is not a problem in ipv4.

> The other solutions do not scale to the size of the Internet;
> I could get BGP at home but I don't want to, it is easier (and cheaper)
> to just restart connections in the rare event of one line breaking.

No, it is not easier to restart connections.  I have a remote ssh
session that has been running for 4 weeks, and 2 of my 4 upstreams
have gone down during that time.

> v4 vs v6 has very little to do with this; the world wants roaming and
> multi-homing, and BGP is not going to give it to the masses. NAT may
> enable multi-homing, but it does nothing to help roaming (on the
> contrary, state in the network makes it harder; and NATs tend to break
> my idle SSH sessions even when there is no fault in any line)

Everyone wants roaming, so stable addressing must die.

Brilliant logic.  Just brilliant.  You will have a brilliant
career at the IETF designing protocols.

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

My upstreams don't blackhole me, since that would be an administrative
procedure.  They don't do it, because it is bad for business.

You cannot equate an administrative procedure which isn't done, to an
engineering mistake which screws everyone.

Reply | Threaded
Open this post in threaded view
|

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

Theo de Raadt
In reply to this post by Jussi Peltola
> On Wed, Oct 24, 2012 at 01:28:38PM -0600, Theo de Raadt wrote:
> > Basically to make IPv6 pseudo-"multihoming" work like IPv4
> > multihoming, ssh and sshd need to be modified that they can handle a
> > network break, and re-connect using another address.
>  
> I fail to see what any of this has to do with address families. You can
> multihome in every way possible in v4 with v6.

This is completely false.  The move forward in v6 is that applications
should handle address changes.  In v4, this is simply not necessary.

> The DFZ will not scale to everyone's iPad having their own prefix,
> sending an update each time they hop on to another network.

Not everything roams.

Reply | Threaded
Open this post in threaded view
|

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

Joel Wirāmu Pauling
In reply to this post by Jussi Peltola
As someone working for a 'Carrier'  vendor - I can tell you straight
up that LSN(Large Scale) or CGN(Carrier Grad) NAT are big sell points
(i.e customers are asking for them).

Personally out of the various RFC's and schemes i've had the
displeasure of perusing for V6 to V4 access NAT64 to me seems to the
be the least evil.

It is the ONLY solution which can easily remove the need for upstream
fiddling if the CPE implements it, i.e the bad stuff at least stays on
the edge of YOUR network. You effectively need the NAT64 module and a
DNS proxy sitting on the CPE - all the various other RFC's require
some level of ISP/Carrier interaction upstream to make things work; or
break in interesting strange ways for the user (not that I am saying
NAT64 is perfect).

I know which I would prefer to see widely adopted.

Also under the general guise of WHY you need NAT at all in IPV6
stacks... the ONE good argument is for easily setup Load Balancing.

-Joel

@aenertia
http://gplus.to/aenertia

Reply | Threaded
Open this post in threaded view
|

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

Jussi Peltola
In reply to this post by Theo de Raadt
On Wed, Oct 24, 2012 at 01:43:01PM -0600, Theo de Raadt wrote:
> Luckily that is not a problem in ipv4.

I can get IPv6 PI and multihome with v6 as it is just like I used to be
able with v4; now there is no more v4 PI at RIPE. But what does this
have to do with the on-wire protocol again?

> > Do your ssh sessions stay up if one of your upstreams starts blackholing
> > but still announces you a full table of routes?
>
> My upstreams don't blackhole me, since that would be an administrative
> procedure.  They don't do it, because it is bad for business.
>
> You cannot equate an administrative procedure which isn't done, to an
> engineering mistake which screws everyone.

I really don't think I'll need to dignify this with a response, but
everyone who has operated a DFZ network knows there are always broken
paths to some destination, and this means broken connectivity until said
paths are manually fixed or routed around.

Reply | Threaded
Open this post in threaded view
|

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

Paul de Weerd
In reply to this post by Simon Perreault-2
On Wed, Oct 24, 2012 at 03:42:52PM -0400, Simon Perreault wrote:
| Le 2012-10-24 15:38, Barbier, Jason a ?crit :
| >>I'm going to wait a long time for a firmware update that makes my
| >>IPv4-only printer speak IPv6.

Even if it did, would you trust that stack on the global (v6)
internet ?

| >Well man there are several stable implementations of 4 to 6 and 6 to 4
| >bridges.
|
| I don't know what kind of "bridges" you're talking about, but I'll
| assume that pf's NAT64 implementation is one of them.

I think he means lpr listening on v6 and pushing out to the v4 address
on the other end.

There's no need for extra shit to do what has been possible for years.

Now, my printer already supports v6 but I still prefer printjobs to be
sent to the workstation next to it running OpenBSD.  For one, because
it has spooling so I don't have to have both devices powered 24/7.
Another reason is the fact that I don't trust the network stack (v4 or
v6) on these HP printers enough to expose it to the internet.
Besides, the printer doesn't do /etc/hosts.lpd or pf to limit incoming
printjobs to my own machines.

Paul 'WEiRD' de Weerd

--
>++++++++[<++++++++++>-]<+++++++.>+++[<------>-]<.>+++[<+
+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
                 http://www.weirdnet.nl/                 

Reply | Threaded
Open this post in threaded view
|

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

Simon Perreault-2
Le 2012-10-24 15:59, Paul de Weerd a écrit :
> On Wed, Oct 24, 2012 at 03:42:52PM -0400, Simon Perreault wrote:
> | Le 2012-10-24 15:38, Barbier, Jason a ?crit :
> | >>I'm going to wait a long time for a firmware update that makes my
> | >>IPv4-only printer speak IPv6.
>
> Even if it did, would you trust that stack on the global (v6)
> internet ?

No, I was thinking of a v6 LAN.

> | >Well man there are several stable implementations of 4 to 6 and 6 to 4
> | >bridges.
> |
> | I don't know what kind of "bridges" you're talking about, but I'll
> | assume that pf's NAT64 implementation is one of them.
>
> I think he means lpr listening on v6 and pushing out to the v4 address
> on the other end.
>
> There's no need for extra shit to do what has been possible for years.

Of course you can do it at any layer you want. There's also faithd if
you want to do it at layer 4. I prefer my translations to be done at
layer 3, thank you very much.

Simon

Reply | Threaded
Open this post in threaded view
|

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

Claudio Jeker
In reply to this post by Simon Perreault-2
On Wed, Oct 24, 2012 at 03:10:29PM -0400, Simon Perreault wrote:
> Le 2012-10-24 14:54, Claudio Jeker a écrit :
> >But less PI space. Since some evangelists belive in the superiority of
> >IPv6 and try everything to make it impossible to get routable PI space.
> >At the moment IPv6 is a step backwards in all regards.
>
> Wait wait wait... what RIR doesn't take "multihoming" as a valid
> justification for getting IPv6 PI space?
>

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.

The system is fucked up and so people will work around it in the worst
ways.
--
:wq Claudio

Reply | Threaded
Open this post in threaded view
|

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

Claudio Jeker
In reply to this post by Jussi Peltola
On Wed, Oct 24, 2012 at 10:12:33PM +0300, Jussi Peltola wrote:
> On Wed, Oct 24, 2012 at 02:43:14PM -0400, Simon Perreault wrote:
> > What you need to multihome is either BGP or NAT. Exactly as in IPv4.
> > Nothing has changed. The only new thing with IPv6 is that there's
> > more bits.
>  
> Oh? I have two internet connections plugged directly into my desktop box
> at home, it is multihomed and there is no BGP or NAT. This does need
> some policy routing to work with uRPF filtered access lines.

This is just the tip of the iceberg.
 
> With IPv6 multihoming should work trivially: plug two access lines into
> a switch, get RAs from both, get addresses from both on your end-host,
> and your end-host needs to select the proper route for each source
> address. Again, no NAT or BGP. Applications will need to support hosts
> having multiple addresses in the future, and happy eyeballs seems to
> have made browsers do that.

Ha ha ha ha, this will work for a single host but how will you manage
multiple ones. Bonus question, how do you think the host router with no
knowledge of the underlying network topology will choose a route?
This setup is one of the biggest mistakes made in IPv6.
 

> There is also a considerable advantage against "multihoming" where hosts
> only have 1 address configured: if the application tries to use all
> source addresses available, you can get to google even if one of your
> access lines has no connectivity to them; with BGP multihoming you will
> not, with v4 NAT style multihoming you possibly can if it does
> round-robin and you try again.
>
> Add SCTP to this puzzle, and you should be able to roam seamlessly from
> WLAN to 3G to WLAN without your ssh sessions breaking. mosh already more
> or less does this. With multiple addresses and default routes per host,
> and SCTP or multipath TCP, you should also be able to load-share one
> connection among multiple internet connections.

Hey, you forgot to mention shim6 and all the other crap ideas that already
died. SCTP is a monster and it is over engineered like IPv6. I wonder when
the first SCTP hacks will apear that take down host and maybe networks.
If I want persistent login sessions I use tmux.
 
> End hosts need to get smarter, instead of the network adapting to their
> stupidity. But I'm not holding my breath.

Nope. End hosts need to stay stupid. They can not handle the truth their
poor little mobile cores would just explode the moment they try to grasp
the real world.

--
:wq Claudio

Reply | Threaded
Open this post in threaded view
|

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

Simon Perreault-2
Le 2012-10-24 16:30, Claudio Jeker a écrit :

>> With IPv6 multihoming should work trivially: plug two access lines into
>> a switch, get RAs from both, get addresses from both on your end-host,
>> and your end-host needs to select the proper route for each source
>> address. Again, no NAT or BGP. Applications will need to support hosts
>> having multiple addresses in the future, and happy eyeballs seems to
>> have made browsers do that.
>
> Ha ha ha ha, this will work for a single host but how will you manage
> multiple ones. Bonus question, how do you think the host router with no
> knowledge of the underlying network topology will choose a route?
> This setup is one of the biggest mistakes made in IPv6.

Careful. What he's talking about is his own proposal, not what IPv6 is.

Simon

Reply | Threaded
Open this post in threaded view
|

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

Jussi Peltola
In reply to this post by Claudio Jeker
On Wed, Oct 24, 2012 at 10:30:21PM +0200, Claudio Jeker wrote:

> On Wed, Oct 24, 2012 at 10:12:33PM +0300, Jussi Peltola wrote:
> > On Wed, Oct 24, 2012 at 02:43:14PM -0400, Simon Perreault wrote:
> > > What you need to multihome is either BGP or NAT. Exactly as in IPv4.
> > > Nothing has changed. The only new thing with IPv6 is that there's
> > > more bits.
> >  
> > Oh? I have two internet connections plugged directly into my desktop box
> > at home, it is multihomed and there is no BGP or NAT. This does need
> > some policy routing to work with uRPF filtered access lines.
>
> This is just the tip of the iceberg.

This is a very common setup for bastion hosts with multiple dsl lines
for redundancy; it is extremely robust against all kinds of failures,
unlike other forms of multihoming.

> > With IPv6 multihoming should work trivially: plug two access lines into
> > a switch, get RAs from both, get addresses from both on your end-host,
> > and your end-host needs to select the proper route for each source
> > address. Again, no NAT or BGP. Applications will need to support hosts
> > having multiple addresses in the future, and happy eyeballs seems to
> > have made browsers do that.
>
> Ha ha ha ha, this will work for a single host but how will you manage
> multiple ones. Bonus question, how do you think the host router with no
> knowledge of the underlying network topology will choose a route?
> This setup is one of the biggest mistakes made in IPv6.
 
Roaming single hosts are a very large subset of all hosts; server-type
systems usually have static configuration anyway. I really don't see how
multiple hosts wouldn't work if one does...

> > There is also a considerable advantage against "multihoming" where hosts
> > only have 1 address configured: if the application tries to use all
> > source addresses available, you can get to google even if one of your
> > access lines has no connectivity to them; with BGP multihoming you will
> > not, with v4 NAT style multihoming you possibly can if it does
> > round-robin and you try again.
> >
> > Add SCTP to this puzzle, and you should be able to roam seamlessly from
> > WLAN to 3G to WLAN without your ssh sessions breaking. mosh already more
> > or less does this. With multiple addresses and default routes per host,
> > and SCTP or multipath TCP, you should also be able to load-share one
> > connection among multiple internet connections.
>
> Hey, you forgot to mention shim6 and all the other crap ideas that already
> died. SCTP is a monster and it is over engineered like IPv6. I wonder when
> the first SCTP hacks will apear that take down host and maybe networks.
> If I want persistent login sessions I use tmux.

Yes, with a while loop trying to ssh and re-attach to screen or tmux
forever you can get pretty close, as with web apps that do transient
http requests.

Again, this has absolutely nothing to do with ipv6; exactly the same
problems and solutions exist on ipv4.

> > End hosts need to get smarter, instead of the network adapting to their
> > stupidity. But I'm not holding my breath.
>
> Nope. End hosts need to stay stupid. They can not handle the truth their
> poor little mobile cores would just explode the moment they try to grasp
> the real world.

What exactly is your proposal? Infinite DFZ growth?

Reply | Threaded
Open this post in threaded view
|

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

Stuart Henderson
In reply to this post by Simon Perreault-2
On 2012-10-24, Simon Perreault <[hidden email]> wrote:

> One use case: ISP who wants to provide IPv4+IPv6 to customers, but does
> not have enough IPv4 addresses for everyone, so has to NAT anyway, and
> wants to simplify the operation of its edge network by running only one
> protocol.
>
> Quite popular with 3GPP folks since they have zillions of customers and
> are already NATing them in IPv4-only, and their handsets all run
> applications coded in a high-level language like Java and therefore
> support IPv6 by default. The notable exception being Skype...
>
> As soon as you provide IPv6, you have a huge chunk of your traffic that
> is IPv6: Google, Facebook, Youtube, Akamai, etc. So NAT64 is only used
> for the remaining mom and pop shops, and www.openbsd.org. And that
> fraction of IPv4-only hosts is diminishing and all signs point to that
> trend continuing.
>
> So these 3GPP providers can go from "NAT everything" to "NAT a little"
> by deploying NAT64. Why would anyone in their right mind not consider that?
>
> Simon
>
>

Another important thing to note here is that with NAT64 the natting
_no longer needs to be in the normal network path_, the translation
gateways can be off to one side without any special tricks, just
normal routing. (Horizontal scaling can even be done by having the
DNS64 push out different prefixes). And as more traffic goes to
native v6, the load on the NAT64 gateways decreases.

VOIP of various kinds over v6 is still a big problem, though I am
sure some of the larger networks interested in protocol transition
would not see that as a disadvantage ;)

Reply | Threaded
Open this post in threaded view
|

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

Stuart Henderson
In reply to this post by Kurt Mosiejczuk
On 2012-10-24, Kurt Mosiejczuk <[hidden email]> wrote:

> Daniel Ouellet wrote:
>
>> Anyone have any possible explication that would actually justify the use
>> of NAT64 that I obviously overlooked?
>
> The one use I could think of us to make your internal network
> independent of your ISP.  Right now, if you change ISPs, your network
> prefix changes and your whole network has to be renumbered.
>
> I read about it in the following article earlier this year.
> http://www.theregister.co.uk/2012/03/31/ipv6_sucks_for_smes/
>
> I'd be happy to have it pointed out to me how the article is wrong, but
> it seemed to point out the ugly corners the IPv6 folks don't talk about.

The difference with v6 is it's designed from the start to work with
multiple addresses on an interface. The source-address selection rules
are rather complex but they do mean you can hand out a ULA prefix as
well as a globally routable prefix, machines will use the ULA for
accessing internal resources but will use a globally routable address
for accessing external sites.

Reply | Threaded
Open this post in threaded view
|

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

Stuart Henderson
In reply to this post by Daniel Ouellet
re-reading this original mail... you're saying NAT64 (which is a form
of protocol translation used in conjunction with special DNS servers,
so v6-only hosts can reach v4 hosts if they are accessed by name)...
but I'm not sure if this matches what the rest of the mail is talking
about, which seems more about NAT in IPv6 in general..


On 2012-10-24, Daniel Ouellet <[hidden email]> wrote:

> Hi,
>
> Just saw a few questions and patch for NAT64 on misc and tech@ and I am
> really questioning the reason to be fore NAT64 and why anyone in their
> right mind would actually want to use this?
>
> NAT always makes connectivity less efficient anyway and was really
> designed to alleviated the lack of IPv4 address years ago and was sadly
> used as a firewall setup by what I would call lazy admin instead if a
> properly configure one.
>
> Call me stupid and I will accept it, but regardless of this why?
>
> NAT was sadly a quick way to setup security and over time become even
> more sadly what some security suppose to be expect call the defacto way
> to do security.
>
> NAT needs to process every packets, changed the header both in incoming
> and outgoing traffic and as bandwidth keep increasing only make the
> totally not optimize NAT table getting bigger 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!
>
> There is even more then this above, but I will spare the list with more
> as my question is really why NAT64?
>
> 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?
>
> Isn't it just a side effect of a sadly miss guided use of NAT in IPv4 as
> a firewall carry over to a IPv6 world instead of starting to do proper
> setup now that IP's will be plentiful anyway?
>
> Anyone have any possible explication that would actually justify the use
> of NAT64 that I obviously overlooked?
>
> Why us it other then for lazy firewall setup these day?
>
> I would appreciate a different point of view that I obviously appear to
> have overlooked as I really don't see why it even exists.
>
> Best,
>
> Daniel

Reply | Threaded
Open this post in threaded view
|

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

Constantine A. Murenin
In reply to this post by Daniel Ouellet
Daniel,

I think you're confused between NAT66 and NAT64. [0]

T-Mobile USA optionally supports IPv6 connectivity in some limited
number of new phones (Galaxy Nexus etc) [1], and when the IPv6 option
is manually activated by the user^w beta-tester on their phone, then
no IPv4 support is provided, and access to IPv4-only resources is
available through NAT64 [2] and DNS64 [3].  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.

Frankly, dual-stacking (with the plain old NAT44) would seem like a
better approach for an end-user; I would guesstimate that less than 1%
of Galaxy Nexus users on T-Mobile USA have actually enabled IPv6 (and
left it enabled after simply testing it), precisely because
dual-stacking is not an option, and T-Mo's NAT64/DNS64 must be
consumed (instead of NAT44), breaking all those crappy apps that
hardcode IPv4 addresses outside of the DNS and such.

C.

[0] https://sites.google.com/site/ipv6implementors/2010/agenda
[1] https://sites.google.com/site/tmoipv6/lg-mytouch
[2] http://tools.ietf.org/html/rfc6146
[3] http://tools.ietf.org/html/rfc6147

On 24 October 2012 09:43, Daniel Ouellet <[hidden email]> wrote:

> Hi,
>
> Just saw a few questions and patch for NAT64 on misc and tech@ and I am
> really questioning the reason to be fore NAT64 and why anyone in their right
> mind would actually want to use this?
>
> NAT always makes connectivity less efficient anyway and was really designed
> to alleviated the lack of IPv4 address years ago and was sadly used as a
> firewall setup by what I would call lazy admin instead if a properly
> configure one.
>
> Call me stupid and I will accept it, but regardless of this why?
>
> NAT was sadly a quick way to setup security and over time become even more
> sadly what some security suppose to be expect call the defacto way to do
> security.
>
> NAT needs to process every packets, changed the header both in incoming and
> outgoing traffic and as bandwidth keep increasing only make the totally not
> optimize NAT table getting bigger 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!
>
> There is even more then this above, but I will spare the list with more as
> my question is really why NAT64?
>
> 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?
>
> Isn't it just a side effect of a sadly miss guided use of NAT in IPv4 as a
> firewall carry over to a IPv6 world instead of starting to do proper setup
> now that IP's will be plentiful anyway?
>
> Anyone have any possible explication that would actually justify the use of
> NAT64 that I obviously overlooked?
>
> Why us it other then for lazy firewall setup these day?
>
> I would appreciate a different point of view that I obviously appear to have
> overlooked as I really don't see why it even exists.
>
> Best,
>
> Daniel

Reply | Threaded
Open this post in threaded view
|

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

Chris Bennett
In reply to this post by Daniel Ouellet
-------- Original Message --------
Subject: Re: Why anyone in their right mind would like to use NAT64
From: Simon Perreault <[hidden email]>
Date: Wed, October 24, 2012 12:33 pm
To: [hidden email]

Le 2012-10-24 15:29, Barbier, Jason a écrit :
> Well expanding on the address space and numbering issue, that would be a
> valid use for NAT but I honestly think it would be better to actually try
> and fix that before trying to put a hack over the top of it.

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

Simon

I have two very old IP print servers that work just fine.
You just have to flip those 4 tiny little switches to get access
to program them over IP. Can I get another tiny switch to add IPv6?

Chris

Reply | Threaded
Open this post in threaded view
|

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

Simon Perreault-2
Le 2012-10-25 07:45, [hidden email] a écrit :
> I have two very old IP print servers that work just fine.
> You just have to flip those 4 tiny little switches to get access
> to program them over IP. Can I get another tiny switch to add IPv6?

You could just map an IPv6 address to them using pf's af-to keyword:

pass in inet6 to 2001:db8::1 af-to inet from 192.0.2.1 to 192.0.2.2

Simon

Reply | Threaded
Open this post in threaded view
|

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

Simon Perreault-4
In reply to this post by Constantine A. Murenin
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".
Currently deployed equipment can not do dual-stack PDP contexts. So if
you want to provide dual-stack to your customers, you need to provide
them each with two single-stack PDP contexts, which doubles the amount
you end up paying in license fees to equipment vendors.

That's going to change in the medium term when new equipment capable of
dual-stack PDP contexts gets deployed. But in the short term, NAT64
looks very attractive.

Simon

123