Re: Why anyone in their right mind would like to use NAT64
sigh. another essay without actual content. * Daniel Ouellet dan...@presscom.net [2012-10-24 20:00]: NAT always makes connectivity less efficient yeah, right. 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, right. 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, h...@bsws.de, henn...@openbsd.org 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/
Re: Why anyone in their right mind would like to use NAT64
* Jussi Peltola pe...@pelzi.net [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, h...@bsws.de, henn...@openbsd.org 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/
Re: Why anyone in their right mind would like to use NAT64
* Otto Moerbeek o...@drijf.net [2012-10-25 16:34]: On Thu, Oct 25, 2012 at 02:23:06PM +, 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, h...@bsws.de, henn...@openbsd.org 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/
Re: Why anyone in their right mind would like to use NAT64
On Wed, 24 Oct 2012 22:16:04 +0200 Claudio Jeker cje...@diehard.n-r-g.com 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.
Re: Why anyone in their right mind would like to use NAT64
Original Message Subject: Re: Why anyone in their right mind would like to use NAT64 From: Simon Perreault sperrea...@openbsd.org Date: Wed, October 24, 2012 12:33 pm To: misc@openbsd.org 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
Re: Why anyone in their right mind would like to use NAT64
Le 2012-10-25 07:45, chrisbenn...@bennettconstruction.us 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
Re: Why anyone in their right mind would like to use NAT64
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
Re: Why anyone in their right mind would like to use NAT64
On 2012-10-25, Simon Perreault si...@nomis80.org 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 ;)
Re: Why anyone in their right mind would like to use NAT64
On Thu, Oct 25, 2012 at 02:23:06PM +, Stuart Henderson wrote: On 2012-10-25, Simon Perreault si...@nomis80.org 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 ;-)
Re: Why anyone in their right mind would like to use NAT64
On Wed, 24 Oct 2012 15:33:55 -0400 Simon Perreault sperrea...@openbsd.org 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...
Re: Why anyone in their right mind would like to use NAT64
Daniel Ouellet dan...@presscom.net writes: 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? The main reason why NAT64 was developed is that in some scenarios it looked like it would save money for budget-constrained organizations of various kinds. Typically these are sites who need various types specialized equipment that is designed to be super-reliable and is insanely expensive to replace. Some of these sites are now facing the requirement to run IPv6 while they also have significant amounts of equipment that needs to be kept running for a hard to determine number of years more even though it is old enough that the manufacturers have declined to offer upgrades that would enable the devices to support IPv6. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Why anyone in their right mind would like to use NAT64
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
Re: Why anyone in their right mind would like to use NAT64
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. --Kurt
Re: Why anyone in their right mind would like to use NAT64
Hello, Le 24/10/2012 18:43, Daniel Ouellet a écrit : 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? What is your proposal to allow a v6-only network to reach a v4-only server ? Denis
Re: Why anyone in their right mind would like to use NAT64
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. But IPV6 is such a brilliant network for creating provider cartels and monopolies! The business case is solid!
Re: Why anyone in their right mind would like to use NAT64
Le 2012-10-24 14:25, Kurt Mosiejczuk a écrit : 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. 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. However, with more bits you have the possibility of using a nicer form of NAT in that statelessly maps one prefix to another: http://tools.ietf.org/html/rfc6296 And here's a draft with more info on how to apply it to multihoming: http://tools.ietf.org/html/draft-bonica-v6-multihome-03 Simon
Re: Why anyone in their right mind would like to use NAT64
On Wed, Oct 24, 2012 at 02:43:14PM -0400, Simon Perreault wrote: Le 2012-10-24 14:25, Kurt Mosiejczuk a écrit : 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. 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. 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. If the idea would be to get everybody to use v6 then the RIR should give out IPv6 ranges like candy -- if you have a PI IPv4 space you should get a PI IPv6 space. But instead people still dream of the 10k routing table... I know one thing for sure. In the next few years the internet will suck. -- :wq Claudio
Re: Why anyone in their right mind would like to use NAT64
On Wed, Oct 24, 2012 at 02:43:14PM -0400, Simon Perreault wrote: Le 2012-10-24 14:25, Kurt Mosiejczuk a écrit : 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. 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. 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. If the idea would be to get everybody to use v6 then the RIR should give out IPv6 ranges like candy -- if you have a PI IPv4 space you should get a PI IPv6 space. But instead people still dream of the 10k routing table... I know one thing for sure. In the next few years the internet will suck. I could not say it better myself. I agree completely.
Re: Why anyone in their right mind would like to use NAT64
On Wed, Oct 24, 2012 at 12:43:12PM -0400, Daniel Ouellet 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? To reach v4 only hosts, d'oh? 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? This is a utopic dream, the reality is /64 or /128s in many places. This is useless for anyone with a router unless you start playing with proxy ndp which will end in tears, or NAT. But I really do not see what on earth does this have to do with NAT64 at all. 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? NAT will not go away, there are plenty of corner cases where it is useful (like managment networks where you cannot put each management interface in a vrf.) Companies will also very likely want to keep private addresses internally; NAT is easier for many cases than having a separate routable address on every host. NAT is a necessary evil, and it really is not that bad when operated voluntarily by the same party as the end-hosts behind it. The real problem is CGN; I doubt any ISP is going to NAT when it is not absolutely necessary because it is expensive and painful.
Re: Why anyone in their right mind would like to use NAT64
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? Simon
Re: Why anyone in their right mind would like to use NAT64
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. 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. 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. End hosts need to get smarter, instead of the network adapting to their stupidity. But I'm not holding my breath.
Re: Why anyone in their right mind would like to use NAT64
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. 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. 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.
Re: Why anyone in their right mind would like to use NAT64
You have IPv4 only applications, that need to talk with the IPv6 internet. On 2012 Oct 24 (Wed) at 12:43:12 -0400 (-0400), Daniel Ouellet 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? -- Pascal, n.: A programming language named after a man who would turn over in his grave if he knew about it. -- Datamation, January 15, 1984
Re: Why anyone in their right mind would like to use NAT64
End hosts need to get smarter, instead of the network adapting to their stupidity. But I'm not holding my breath. No, what you are really saying is that non-transient network traffic (long lived TCP sessions) need to have the applications talking them -- and obviously the protocols also -- modified, adding great additional complexity, to sure that they can keep traffic moving when the routing part of the protocol fails to do, uhm, ROUTING. So, to make this clear with an example. 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. (Yes, I know there are a few places where this can be solved, using various tools now being discussed, which means the BIG GUYS can avoid this problems, but the LITTLE PEOPLE can't). Awesome. Totally awesome. Pushing additional complexity into applications is retarded. The IETF is run by a bunch of idiots.
Re: Why anyone in their right mind would like to use NAT64
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. In theory you could do it with routing tables but I could be retarded also so. On Wed, Oct 24, 2012 at 12:24 PM, Peter Hessler phess...@theapt.org wrote: You have IPv4 only applications, that need to talk with the IPv6 internet. On 2012 Oct 24 (Wed) at 12:43:12 -0400 (-0400), Daniel Ouellet 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? -- Pascal, n.: A programming language named after a man who would turn over in his grave if he knew about it. -- Datamation, January 15, 1984 -- Jason Barbier Pro Patria Vigilans
Re: Why anyone in their right mind would like to use NAT64
On Wed, Oct 24, 2012 at 02:25:07PM -0400, Kurt Mosiejczuk wrote: I read about it in the following article earlier this year. http://www.theregister.co.uk/2012/03/31/ipv6_sucks_for_smes/ Everybody except a few zealots have accepted the fact that NAT will exist in ipv6 just like v4. The difference is that you are no longer forced into using NAT by address scarcity, you get to choose if you want to use it or not. That article paints a picture of NAT as some kind of silver bullet that solves everything; I'll not bother arguing against that. The article also completely misses some of the proposed solutions, like running multiple prefixes for multihoming, and having a ULA prefix for internal communication and a dynamically assigned global one for external connectivity. Yes, you get to change DNS entries for your publicly-accessible hosts when you change ISPs if you use provider allocated addresses - how does NAT help with this again, except add the extra work of changing NAT translation rules?
Re: Why anyone in their right mind would like to use NAT64
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 On Wed, Oct 24, 2012 at 12:24 PM, Peter Hesslerphess...@theapt.org wrote: You have IPv4 only applications, that need to talk with the IPv6 internet.
Re: Why anyone in their right mind would like to use NAT64
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. 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. 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) Do your ssh sessions stay up if one of your upstreams starts blackholing but still announces you a full table of routes?
Re: Why anyone in their right mind would like to use NAT64
On Wed, Oct 24, 2012 at 12:33 PM, Simon Perreault sperrea...@openbsd.orgwrote: 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
Re: Why anyone in their right mind would like to use NAT64
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.
Re: Why anyone in their right mind would like to use NAT64
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
Re: Why anyone in their right mind would like to use NAT64
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.
Re: Why anyone in their right mind would like to use NAT64
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.
Re: Why anyone in their right mind would like to use NAT64
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.
Re: Why anyone in their right mind would like to use NAT64
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
Re: Why anyone in their right mind would like to use NAT64
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/
Re: Why anyone in their right mind would like to use NAT64
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
Re: Why anyone in their right mind would like to use NAT64
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
Re: Why anyone in their right mind would like to use NAT64
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
Re: Why anyone in their right mind would like to use NAT64
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
Re: Why anyone in their right mind would like to use NAT64
Le 2012-10-24 15:12, Jussi Peltola a écrit : 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. 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. Source-based routing is arguably not multihoming, depending on your definition of multihoming. It's not new to IPv6 either. 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. 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, Oh, that's the new thing you're proposing: happy eyeballs on source addresses. Interesting... you can get to google even if one of your access lines has no connectivity to them; with BGP multihoming you will not, If you can't trust the routes you receive over BGP, you're kinda screwed anyway. Simon
Re: Why anyone in their right mind would like to use NAT64
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?
Re: Why anyone in their right mind would like to use NAT64
On 2012-10-24, Simon Perreault sperrea...@openbsd.org 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 ;)
Re: Why anyone in their right mind would like to use NAT64
On 2012-10-24, Kurt Mosiejczuk kurt-openbsd-m...@se.rit.edu 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.
Re: Why anyone in their right mind would like to use NAT64
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 dan...@presscom.net 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
Re: Why anyone in their right mind would like to use NAT64
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 dan...@presscom.net 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
