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 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: First order for KVM SWITCH -- Esunlink
Dear Purchasing Manager, Good day! Esunlink is professional Manufacturer which specialize in KVM Switch& Accessories with high quality and reasonable price,OEM/ODM Services also can be offered upon your special request . We get a lot of high praise from our Long-term cooperation customers--- Lenovo, ZTE ,Huawei, etc. Some products as below for your reference: For more information, please log on: www.esunlink.com. Always here to support you! Best regards, [demime 1.01d removed an attachment of type image/jpeg which had a name of Catch(09-26-15-2(10-25-10-30-52).jpg] [demime 1.01d removed an attachment of type image/jpeg which had a name of =?gb2312?B?NDY1MDNfw/vGrCgwOS0yNS0xKDEwLTI1LTEwLTMwLTUyKS5qcGc=?=]
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 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
On 2012-10-24, Kurt Mosiejczuk 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
On 2012-10-24, Simon Perreault 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: http/https timeouts with OpenBSD based firewall
On 23 October 2012 12:53, Joel Sing wrote: > Unfortunately we have no idea what firewall rules you have configured, however > I'm going to take random guess and say that you're using a scrub rule > with 'reassemble tcp' - if this is the case you'll probably find that some > TCP connections to Windows-based servers will fail, since they often violate > RFC1323 by using a 0-value timestamp during the three-way handshake, then > increase it by some value between 0 and 2^31 on the first data packet. Note > the TS val fields in the first two packets from 64.79.160.13: Joel, your guess was spot on. Removing "reassemble tcp" from scrub rule indeed resolved the issue. Thank you very much! Out of interest - it seems like Windows 2008/2012 behave much better here as I did not experience such problems with these systems. Is it the case or was I just lucky? Thanks again! -- Marcin
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
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
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
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
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
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: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
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 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
> 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: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
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: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
On Wed, Oct 24, 2012 at 12:33 PM, Simon Perreault 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
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
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 Hessler 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 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
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 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
> 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
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
> 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.
Curso de “Desarrollo de Competencias para Asistentes Administrativas y Secretarias”
Si no puede visualizar correctamente las imagenes de este correo, le pedimos que lo arrastre a su Bandeja de Entrada Apreciable Ejecutivo: TIEM de México Empresa Líder en Capacitación y Actualización de Capital Humano Debido al gran éxito obtenido, ponemos nuevamente a su disposición este excelente curso denominado: Desarrollo de Competencias para Asistentes Administrativas y Secretarias 31 de Octubre de 2012 Ciudad de Méxicoy 12 de Noviembre de 2012 Guadalajara Inscríbase 5 días antes de la fecha del Curso y obtenga un descuento del 15% con Inversión Inmediata O b ien, por cada dos participantes inscritos en tarifa de Inversión normal, el tercero es completamente gratis No deje pasar esta oportunidad e Invierta en su Desarrollo Personal y Profesional Las funciones de las Asistentes Ejecutivas y Secretarias de hoy continúan evolucionando hacia nuevos retos y obligaciones que requieren de madurez, profesionalismo y responsabilidad. La Asistente Ejecutiva de Hoy deja sus funciones tradicionales y se orienta a la tendencia de desarrollar actividades de mayor asistencia y apoyo a las direcciones y gerencias. Tu participación te permitirá: Identificar las competencias básicas en la función de asistentes ejecutivas y secretarias, practicando herramientas que les permitan optimizar su trabajo y mejorar su calidad de servicio. Afianzar la Calidad de la Gestión Profesional para Contribuir con la Excelencia Empresarial. Fortalecer Conocimientos y Técnicas Orientadas a los Nuevos Roles que son de tu Competencia. Contaras con Herramientas que te Permitan Manejar Mejor las Situaciones Estresantes, dentro de tus Actividades Profesionales, Personales y Familiares. Proyectar la Actividad Laboral en Armonía con la Actividad Familiar para Construir una Trascendencia Ejemplar y Positiva en cada uno de los Diferentes Ámbitos. Para mayor información, favor de responder este correo con los siguientes datos: Empresa: Nombre: Ciudad: Teléfono: O si lo prefiere comuníquese a los teléfonos: Del DF al 5611-0969 con 10 líneas Interior del País Lada sin Costo 01 800 900 TIEM (8436) Aceptamos todas las TDC y Débito. **Promoción: 3 meses sin Intereses pagando con American Express **Aplica solo con Inversión Normal ®Todos los Derechos Reservados ©2011 TIEM Talento e Innovación Empresarial de México Este Mensaje le ha sido enviado como usuario de TIEM de México o bien un usuario le refirió para recibir este boletín. Como usuario de TIEM de México, en este acto autoriza de manera expresa que TIEM de México le puede contactar vía correo electrónico u otros medios. Si usted ha recibido este mensaje por error, haga caso omiso de él y reporte su cuenta respondiendo este correo con el subject BAJABD Tenga en cuenta que la gestión de nuestras bases de datos es de suma importancia y no es intención de la empresa la inconformidad del receptor.
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
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 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
> 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 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
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
> > 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
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
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
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 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.
Why anyone in their right mind would like to use NAT64
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: GPU driver for Raspberry Pi open sourced
No, it was not open sourced. All they did was release some userland wrappers around their api. No, this does not make it closer to OpenBSD being ported to this device. Nothing has changed. On 2012 Oct 24 (Wed) at 08:56:29 -0700 (-0700), Gene wrote: :http://www.raspberrypi.org/archives/2221 : :Are we any closer to seeing OpenBSD ported to this device? : :-Gene : -- Real computer scientists don't program in assembler. They don't write in anything less portable than a number two pencil.
Re: GPU driver for Raspberry Pi open sourced
> http://www.raspberrypi.org/archives/2221 Well, they are lying to everyone. Their "open source" is nothing but a layer of code which calls into a closed source back-end.
Re: How to delete this partial package?
Marc Espie wrote: > As far as removing the package, since it's just trying to checksum the file > before removing it, pkg_delete -c will take care of that... That's pkg_delete -q -- Christian "naddy" Weisgerber na...@mips.inka.de
Here are the first artist confirmations
Sollte der Inhalt dieser E-Mail nicht korrekt dargestellt werden, klicke bitte hier: http://newsletter.ctek.ch/browser.php?key=7275-5A-01-8625D75DAC7E2D82973F121B 54E19E58-DA84F230DDA30F1E556&rid=01_03_04_51
Re: Problem with server upgrade, upgrade or hardware failure?
On 2012-10-22, wrote: > I did an update to my remote server using the ssh method, since I did > not have Java built > But it failed to reboot Note that this method is likely to have problems going from 5.1 to 5.2 on i386 due to ld.so changes, I would strongly recommend people have console access and remote reboot for this particular upgrade. (just i386; amd64 is not affected by that particular change). The problem I'm thinking of is not the one you are seeing though. > From an IP KVM on someone elses computer with Java. > Boots into ddb right after boot> > (with message below) > > However, after I type boot -s to get into single user mode, I get ddb > with a message similar to: > > kernal protection fault trap > Stopped at calibrate_cyclecounter, etc The rest of the information in that message might be useful. And of course other standard information: - How old was the working version? - What are you updating to now? - Which arch? > If I type boot> boot bsd.rd, > the server immediately shuts down and reboots > I am building Java right now. > > Does this sound like a hardware failure or bad upgrade?? Can't say from the information given. Did you save an old kernel/bsd.rd? Does that fail too? > I am going to try upgrade with IP KVM after Java finishes building > Java built but I cannot get firefox35 to work. > I am on latest snapshot for i386 > [Exception... "Component returned failure code: 0x80570016 > (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]" nsresult: > "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)" location: "JS frame :: > chrome://browser/content/utilityOverlay.js :: getShellService :: line > 312" data: no] Probably better to report the two problems separately, the problem with building/using java isn't of much use to people who might look at the kernel crash, and vice-versa.
Re: Slow VPN Performance
On 2012-10-24, Michael Sideris wrote: > Also, OpenBSD 5.2 is around the corner and you never know what that might > bring. There's a commit from just after 5.2 which is relevant to some packet forwarding setups, which might be of interest.. http://www.openbsd.org/cgi-bin/cvsweb/src/sys/netinet/ip_input.c?r1=1.197;f=h#rev1.197
cwm(1) and java X gui apps (geo/josm) - keyboard shortcuts ignored
hello folks, I have a problem with geo/josm keyboard shortcuts under cwm(1). fvwm(1) does not show this problem. other apps (e.g. graphics/qiv) do not show the problem under cwm(1). Therefore it appears to me it's a combination of java X gui apps and cwm(1) that eats the keyboard shortcuts. symptoms: keyboard shortcuts (ctrl+q, ctrl+o, ...) have no effect. Some simple keystrokes behave equally bad: opening a menu with the mouse, navigating up/down with the up/down keys does not work. normal text input in dialogs works. wanted: clue sticks, help on debugging. note: before you say: "hey, you are using a X gui app, so darn use your mouse" please note that josm is close to unusable without keyboard shortcuts. jxplorer and projectlibre (as other java X gui apps) do not seem to use keyboard shortcuts at all or I could not find them. Thus I could not test whether they behave differently. Thanks for your time, Marcus
Re: Slow VPN Performance
Actually, scratch that. I was looking at nfs(5) from an old SL 5.7 box I have here which explicitly states: "tcpMount the NFS filesystem using the TCP protocol. This is the default protocol." This is not the case anymore though, thanks for bringing that to my attention. On Wed, Oct 24, 2012 at 10:27 AM, Philip Guenther wrote: > On Wed, Oct 24, 2012 at 12:57 AM, Michael Sideris wrote: >> I am using the NFS defaults which means, according to the man page at >> least, that it should go over TCP. > > Hmm, I don't believe that to be the case. What man page text are you > seeing says the default is TCP? > > > Philip Guenther
Re: Slow VPN Performance
On Wed, Oct 24, 2012 at 12:57 AM, Michael Sideris wrote: > I am using the NFS defaults which means, according to the man page at > least, that it should go over TCP. Hmm, I don't believe that to be the case. What man page text are you seeing says the default is TCP? Philip Guenther
Re: Slow VPN Performance
I am using the NFS defaults which means, according to the man page at least, that it should go over TCP. Regardless, I think I have a fair idea of what is what happening now. Or at least better than I had before. I will try to tweak things around a bit until I find the right balance between performance and security. Also, OpenBSD 5.2 is around the corner and you never know what that might bring. Big thanks to everyone who put the time into answering my questions. Cheers! On Tue, Oct 23, 2012 at 5:26 PM, Mike Belopuhov wrote: > On Tue, Oct 23, 2012 at 10:18 AM, Michael Sideris wrote: >> While I am not required to comply with any particular crypto >> standards, I have NFS data passing through that link which I would >> classify asfairly sensitive. > > hmm, if you're using udp mounts for NFS you might want to try tcp > instead. > >> That being said, I am not sure how to >> check the re-keying frequency except watching `ipsecctl -m`. > > that depends on the isakmpd settings. right now you're probably > using default ones which are negotiated with your peer. this is > what isakmpd.conf(5) has to say about it: > > The Quick Mode lifetime defaults to 20 minutes (minimum 60 > seconds, maximum 1 day). > > this is rather a broad range, so you might want to shorten it. > look for the "Default-phase-2-lifetime" parameter in the man > page for the /etc/isakmpd/isakmpd.conf. > >> I am not >> sure if PFS is enabled by default on a stock OpenBSD 5.1 installation >> so I would appreciate it if you could tell me how I can check that. >> > > it is, unless you disable it with the "group none" in the "quick" > configuration options. > >> Performance wise I would be happy if I could squeeze ~100 out of the >> 150Mbit/s link. At the moment I am struggling to reach ~100Mbit/s and >> that is with hmac-md5. I would like to find a reasonable balance >> between performance and security but it seems that hmac-sha2-256 is >> too "expensive" for my hardware. > > unfortunately it is expensive for any hardware that's why aes-gcm > was developed. > >> I really thought dual Xeons @ 2.8GHz would be up to the task. >> > > the "dual" part doesn't help as much as it could though. > > in any case, i suggest you play with nfs tcp mounts and mss fixups. > otherwise you might be loosing performance where you shouldn't. > > trying the snapshot out might also give an opportunity to learn if > some of the performance changes that were committed are helpful > in your setup. > >> On Mon, Oct 22, 2012 at 6:41 PM, Mike Belopuhov wrote: >>> On Mon, Oct 22, 2012 at 4:10 PM, Michael Sideris wrote: It seems that changing to hmac-md5 boosted network throughput from ~50Mbit/s to ~100Mbit/s which is decent and reasonable. I am going to experiment a bit further with `scrub` options in pf.conf to see if I can squeeze more performance out of the link. The question now ishow much is security affected by using hmac-md5 vs the default hmac-sha2-256? >>> >>> It's more a question of how often do you rekey? You also should not >>> disable Perfect Forward Secrecy that recomputes DH values every >>> time you renew your phase 2 key. And while there are no known >>> serious attacks on HMAC-MD5 it all depends on how important the >>> data that you're protecting is and if you have to be compliant with >>> any regulations that might mandate use of SHA2. >>> Should I consider using better CPUs on the servers in order to gain better performance through a stronger algorithm? >>> >>> You can get 600-750Mbps (depending on the CPU speed) in the >>> AES-NI enabled setup (using AES-GCM that is). >>> On Mon, Oct 22, 2012 at 2:58 PM, Mike Belopuhov wrote: > On Tue, Oct 16, 2012 at 11:43 AM, Michael Sideris > wrote: >> Both endpoints run stock OpenBSD 5.1 (amd64). We use the VPN link to >> manage our platform remotely and perform daily backups. G-VPN runs on >> a 150Mbit/s link while L-VPN on a 1Gbit/s link. On one hand, our VPN >> setup runs really nicely. The connections are routed properly, pf is >> godsent and authpf works wonders. On the other hand, network >> throughput over the VPN tunnel never exceeds 3.4MB/s (ftp, scp, rsync, >> etc...) >> >> I welcome any suggestions. Keep in mind that this is our production >> VPN tunnel, so I cannot shut it down at will. Thanks in advance. >> >> --- >> Mike >> > > Hi, > > I suggest a couple of changes: > > 1) use cheaper hash function (md5 or at least sha1) > 2) use mss fixup so that your packets don't get fragmented > > The first point relates to your "ike" rules in ipsec.conf: > > ike esp from $local_net to $remote_net peer $remote_ip \ > quick auth hmac-md5 enc aes > > The second point relates to pf rules in pf.conf: > > match in scrub (max-mss 1440) > > You can experiment with the values in the 1400-1480 range. >>
