RE: Your Christmas Bonus Has Arrived
> -Original Message- > From: Chaim Rieger [mailto:chaim.rie...@gmail.com] > Sent: 14 December 2011 06:10 > To: IPv4 Brokers; nanog@nanog.org > Subject: Re: Your Christmas Bonus Has Arrived > > What do you have for those that don't do the whole Jesus thing ? > That would be Hell.. -- Leigh __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __
Re: Sad IPv4 story?
I really didn't follow to much of this thread, it's all a bit weird with some obvious industry under currents running that I don't follow. What I will say is that I'm currently involved with exactly this issue and would have to say that it's all just getting sillier by the day. I've been researching solutions with NAT and double NAT in mind because it's obvious that v4 space is going to become a growing problem. It's interesting to see the things that break when you use double NAT. What's also interesting is the growing competitive market place with incumbent providers, who have enough v4 space for their entire market, contracting their retail operations while their retail competitors are growing in size. I've been working on some very basic projections for my country and expect over the next decade we will see at least 30%, or more, movement in our market. So where is this going to leave v4 allocations? Will the incumbents protect their retail operations by locking up their v4 space so that smaller competitors can't grow? Will we all move to v6 to make the problem go away? (Not likely, the level of edge understanding of v6 isn't there, and you lot already had a rant about CPE this week, so I won't go there!) Will we develop smarter v4 technology and just NAT on NAT... and on NAT? The only thing that is really clear is the lack of clarity. D On 10/12/2011 7:37 a.m., Franck Martin wrote: I just had a personal email from a brand new ISP in the Asia-Pacific area desperately looking for enough IPv4 to be able to run their business the way they would like… This is just a data point. -- Don Gould 31 Acheson Ave Mairehau Christchurch, New Zealand Ph: + 64 3 348 7235 Mobile: + 64 21 114 0699
Re: Your Christmas Bonus Has Arrived
Is there a comapny behind that gmail mailbox? And they could make a deal with MS & Borders using the same mailbox? -- Babak Farrokhi On Dec 14, 2011, at 9:10 AM, "Patrick W. Gilmore" wrote: > On Dec 13, 2011, at 11:56 PM, Justin M. Streiner wrote: >> On Wed, 14 Dec 2011, Matt Taylor wrote: >>> On 14/12/2011 2:13 PM, IPv4 Brokers wrote: We are paying up-front (or escrow) for the use of networks that are not used. The networks are used for honeypots and other research. The networks may be used for a month or longer, you are paid an agreed upon price per each month of use. We do require a minimum of /24. >> >> Sounds like another middleman for 'bulletproof' hosting services for people >> who generally are up to no good. > > I believe this company is the one that sold the MS & Borders blocks, so they > may be "legit" (whatever that means in this context). > > Also, they may be using a GMail account because it is likely they crossed > some line with people (perhaps even the NANOG mail admins) and need a > disposable account. > > Or maybe they really are running their business off *@gmail.com > > -- > TTFN, > patrick > >
Re: Your Christmas Bonus Has Arrived
What do you have for those that don't do the whole Jesus thing ?
Re: Your Christmas Bonus Has Arrived
On Tue, 13 Dec 2011 23:56:19 EST, "Justin M. Streiner" said: > As far as I'm concerned, they can have as much of 10/8 as they want. My > rate per /24 is very reasonable. Oh, I don't think they'll fall for that, everbody knows 10/8 and 192.168/16 are private networks. However, I bet I can underbid Justin with some of the /24's off the end of 172.16/12 - my HPC people aren't using anywhere near the whole allocation and will never notice a bunch of /24's off the end. ;) pgp9ZhQuiesAB.pgp Description: PGP signature
Re: Your Christmas Bonus Has Arrived
On Dec 13, 2011, at 11:56 PM, Justin M. Streiner wrote: > On Wed, 14 Dec 2011, Matt Taylor wrote: >> On 14/12/2011 2:13 PM, IPv4 Brokers wrote: >>> We are paying up-front (or escrow) for the use of networks that are not >>> used. The networks are used for honeypots and other research. >>> >>> The networks may be used for a month or longer, you are paid an agreed >>> upon price per each month of use. >>> >>> We do require a minimum of /24. > > Sounds like another middleman for 'bulletproof' hosting services for people > who generally are up to no good. I believe this company is the one that sold the MS & Borders blocks, so they may be "legit" (whatever that means in this context). Also, they may be using a GMail account because it is likely they crossed some line with people (perhaps even the NANOG mail admins) and need a disposable account. Or maybe they really are running their business off *@gmail.com -- TTFN, patrick
Re: Your Christmas Bonus Has Arrived
On Wed, 14 Dec 2011, Matt Taylor wrote: On 14/12/2011 2:13 PM, IPv4 Brokers wrote: We are paying up-front (or escrow) for the use of networks that are not used. The networks are used for honeypots and other research. The networks may be used for a month or longer, you are paid an agreed upon price per each month of use. We do require a minimum of /24. Sounds like another middleman for 'bulletproof' hosting services for people who generally are up to no good. As far as I'm concerned, they can have as much of 10/8 as they want. My rate per /24 is very reasonable. jms
Re: Your Christmas Bonus Has Arrived
... Heh > > ipv4brok...@gmail.com > > -.- > > If domain squatting and patent trolling are both legitimate sometimes multi-million dollar businesses are you really surprised?
Re: Your Christmas Bonus Has Arrived
Do the blocks have to come from a company I still work for? If not I have a boat load.. 2011/12/13 IPv4 Brokers > Do you have subnets that are not in use, or only used for specific > purposes? If so, please contact us. > > We are paying up-front (or escrow) for the use of networks that are not > used. The networks are used for honeypots and other research. > > You do not have to modify your BGP announcements, establish a GRE tunnel to > our network and forward packets over the tunnel. > > The networks may be used for a month or longer, you are paid an agreed upon > price per each month of use. > > Your confidentiality is absolutely guaranteed. Only you will know that > you're making money on your un-used or single/special-use networks. > > We do require a minimum of /24. > >
Re: Your Christmas Bonus Has Arrived
On 14/12/2011 2:13 PM, IPv4 Brokers wrote: Do you have subnets that are not in use, or only used for specific purposes? If so, please contact us. We are paying up-front (or escrow) for the use of networks that are not used. The networks are used for honeypots and other research. You do not have to modify your BGP announcements, establish a GRE tunnel to our network and forward packets over the tunnel. The networks may be used for a month or longer, you are paid an agreed upon price per each month of use. Your confidentiality is absolutely guaranteed. Only you will know that you're making money on your un-used or single/special-use networks. We do require a minimum of /24. ... Heh ipv4brok...@gmail.com -.- Matt.
Your Christmas Bonus Has Arrived
Do you have subnets that are not in use, or only used for specific purposes? If so, please contact us. We are paying up-front (or escrow) for the use of networks that are not used. The networks are used for honeypots and other research. You do not have to modify your BGP announcements, establish a GRE tunnel to our network and forward packets over the tunnel. The networks may be used for a month or longer, you are paid an agreed upon price per each month of use. Your confidentiality is absolutely guaranteed. Only you will know that you're making money on your un-used or single/special-use networks. We do require a minimum of /24.
EFF call for signatures from Internet engineers against censorship
(Apologies for an slightly-OT posting) Last year, EFF organized an open letter from network engineers against Internet censorship legislation being considered by the US Senate (https://eff.org/deeplinks/2010/09/open-letter). Along with other activists' efforts, we successfully delayed that proposal, but the letter needs to be updated for two bills, SOPA and PIPA, that are close to passing through US Congress now. If you would like to sign, please email me at p...@eff.org, with a one-line summary of what part of the Internet you helped to helped to design, implement, debug or run. We need signatures by 8am GMT on Thursday (midnight Wednesday US Pacific, 3am US Eastern). Also feel free to forward this to colleagues who played a role in designing and building the network. The updated letter's text is below: We, the undersigned, have played various parts in building a network called the Internet. We wrote and debugged the software; we defined the standards and protocols that talk over that network. Many of us invented parts of it. We're just a little proud of the social and economic benefits that our project, the Internet, has brought with it. Last year, many of us wrote to you and your colleagues to warn about the proposed "COICA" copyright and censorship legislation. Today, we are writing again to reiterate our concerns about the SOPA and PIPA derivatives of last year's bill, that are under consideration in the House and Senate. In many respects, these proposals are worse than the one we were alarmed to read last year. If enacted, either of these bills will create an environment of tremendous fear and uncertainty for technological innovation, and seriously harm the credibility of the United States in its role as a steward of key Internet infrastructure. Regardless of recent amendments to SOPA, both bills will risk fragmenting the Internet's global domain name system (DNS) and have other capricious technical consequences. In exchange for this, such legislation would engender censorship that will simultaneously be circumvented by deliberate infringers while hampering innocent parties' right and ability to communicate and express themselves online. All censorship schemes impact speech beyond the category they were intended to restrict, but these bills are particularly egregious in that regard because they cause entire domains to vanish from the Web, not just infringing pages or files. Worse, an incredible range of useful, law-abiding sites can be blacklisted under these proposals. In fact, it seems that this has already begun to happen under the nascent DHS/ICE seizures program. Censorship of Internet infrastructure will inevitably cause network errors and security problems. This is true in China, Iran and other countries that censor the network today; it will be just as true of American censorship. It is also true regardless of whether censorship is implemented via the DNS, proxies, firewalls, or any other method. Types of network errors and insecurity that we wrestle with today will become more widespread, and will affect sites other than those blacklisted by the American government. The current bills -- SOPA explicitly and PIPA implicitly -- also threaten engineers who build Internet systems or offer services that are not readily and automatically compliant with censorship actions by the U.S. government. When we designed the Internet the first time, our priorities were reliability, robustness and minimizing central points of failure or control. We are alarmed that Congress is so close to mandating censorship-compliance as a design requirement for new Internet innovations. This can only damage the security of the network, and give authoritarian governments more power over what their citizens can read and publish. The US government has regularly claimed that it supports a free and open Internet, both domestically and abroad. We cannot have a free and open Internet unless its naming and routing systems sit above the political concerns and objectives of any one government or industry. To date, the leading role the US has played in this infrastructure has been fairly uncontroversial because America is seen as a trustworthy arbiter and a neutral bastion of free expression. If the US begins to use its central in the network for censorship that advances its political and economic agenda, the consequences will be far-reaching and destructive. Senators, Congressmen, we believe the Internet is too important and too valuable to be endangered in this way, and implore you to put these bills aside. -- Peter Eckersleyp...@eff.org Technology Projects Director Tel +1 415 436 9333 x131 Electronic Frontier FoundationFax +1 415 436 9993
Re: recommendations for external montioring services?
Solar winds as you send in the specific mib required to monitor and a week later it's general release Sent from my iPhone On 2011-12-13, at 7:11 PM, "Robert Brockway" wrote: > On Mon, 12 Dec 2011, Eric J Esslinger wrote: > >> I'm not looking to monitor a massive infrastructure: 3 web sites, 2 >> mail >> servers (pop,imap,submission port, https webmail), 4 dns servers >> (including lookups to ensure they're not listening but not >> talking), and >> one inbound mx. A few network points to ping to ensure connectivity >> throughout my system. Scheduled notification windows (for example, >> during work hours I don't want my phone pinged unless it's everything >> going offline. Off hours I do. Secondary notifications if problem >> persists to other users, or in the event of many triggers. That >> sort of >> thing). Sensitivity settings (If web server 1 shows down for 5 min, >> that's not a big deal. Another one if it doesn't respond to repeated >> queries within 1 minute is a big deal) A Weekly summary of issues >> would >> be nice. (especially the 'well it was down for a short bit but we >> didn't >> notify as per settings') I don't have a lot of money to throw at >> this. I > > Hi Eric. The feature set you are describing should be in any > monitoring > system worthy of the name. I've used Nagios to good effect for the > best > part of the last 12 years or so. Before that I used Big Brother, > which > sucked in various ways. > > I did an evaluation on a wide variety of FOSS monitoring systems 2-3 > years > ago and Nagios won at the time (again). Generally I found the > alternatives had problems that I considered to be quite serious > (such as > being overly complicated or doing checks so frequently that they > loaded > the systems they were supposed to be monitoring[1]). > > I'm currently trialing Icinga, a fork of Nagios. > > Puppet can be set up to manage Nagios/Icinga config which cuts down > on the > admin overhead. > > Nagios/Icinga can be hooked up to Collectd to provide performance > data as > well as alert monitoring. > > One concern about external monitoring services is the level of > visibility > they need to have in to your network to adequately monitor them. > > My recommendation is to do a proper risk assessment on the available > options. > >> DO have detailed internal monitoring of our systems but sometimes >> that >> is not entirely useful, due to the fact that there are a few 'single >> points of failure' within our network/notification system, not to >> mention if the monitor itself goes offline it's not exactly going >> to be >> able to tell me about it. (and that happened once, right before the >> mail >> server decided to stop receiving mail). > > There are a couple of ways to deal with this. Some monitoring > applications can fail-over to a standby server if the primary > fails. But > this isn't even really necessary. You will arguably gain higher > reliability by running multiple _independent_ monitors and have them > monitor each other[2]. I have often used this approach. > > The principal aim here is to guarantee that you are alerted to any > single > failure (a production service, system or a monitor). Multiple > simultaneous failures could still produce a blackspot. It is > possible to > design a system that will discover multiple simultaneous failures, > but it > takes more effort and resources. > > > [1] Sometimes I wonder if the people developing certain systems have > any > operational experience at all. > > [2] A system designed to fail-over on certain conditions may fail to > fail-over, ah, so to speak. > > Cheers, > > Rob > > -- > Email: rob...@timetraveller.orgLinux counter ID #16440 > IRC: Solver (OFTC & Freenode) > Web: http://www.practicalsysadmin.com > Director, Software in the Public Interest (http://spi-inc.org/) > Free & Open Source: The revolution that quietly changed the world > "One ought not to believe anything, save that which can be proven by > nature and the force of reason" -- Frederick II (26 December 1194 – > 13 December 1250)
Re: recommendations for external montioring services?
On Mon, 12 Dec 2011, Eric J Esslinger wrote: I'm not looking to monitor a massive infrastructure: 3 web sites, 2 mail servers (pop,imap,submission port, https webmail), 4 dns servers (including lookups to ensure they're not listening but not talking), and one inbound mx. A few network points to ping to ensure connectivity throughout my system. Scheduled notification windows (for example, during work hours I don't want my phone pinged unless it's everything going offline. Off hours I do. Secondary notifications if problem persists to other users, or in the event of many triggers. That sort of thing). Sensitivity settings (If web server 1 shows down for 5 min, that's not a big deal. Another one if it doesn't respond to repeated queries within 1 minute is a big deal) A Weekly summary of issues would be nice. (especially the 'well it was down for a short bit but we didn't notify as per settings') I don't have a lot of money to throw at this. I Hi Eric. The feature set you are describing should be in any monitoring system worthy of the name. I've used Nagios to good effect for the best part of the last 12 years or so. Before that I used Big Brother, which sucked in various ways. I did an evaluation on a wide variety of FOSS monitoring systems 2-3 years ago and Nagios won at the time (again). Generally I found the alternatives had problems that I considered to be quite serious (such as being overly complicated or doing checks so frequently that they loaded the systems they were supposed to be monitoring[1]). I'm currently trialing Icinga, a fork of Nagios. Puppet can be set up to manage Nagios/Icinga config which cuts down on the admin overhead. Nagios/Icinga can be hooked up to Collectd to provide performance data as well as alert monitoring. One concern about external monitoring services is the level of visibility they need to have in to your network to adequately monitor them. My recommendation is to do a proper risk assessment on the available options. DO have detailed internal monitoring of our systems but sometimes that is not entirely useful, due to the fact that there are a few 'single points of failure' within our network/notification system, not to mention if the monitor itself goes offline it's not exactly going to be able to tell me about it. (and that happened once, right before the mail server decided to stop receiving mail). There are a couple of ways to deal with this. Some monitoring applications can fail-over to a standby server if the primary fails. But this isn't even really necessary. You will arguably gain higher reliability by running multiple _independent_ monitors and have them monitor each other[2]. I have often used this approach. The principal aim here is to guarantee that you are alerted to any single failure (a production service, system or a monitor). Multiple simultaneous failures could still produce a blackspot. It is possible to design a system that will discover multiple simultaneous failures, but it takes more effort and resources. [1] Sometimes I wonder if the people developing certain systems have any operational experience at all. [2] A system designed to fail-over on certain conditions may fail to fail-over, ah, so to speak. Cheers, Rob -- Email: rob...@timetraveller.org Linux counter ID #16440 IRC: Solver (OFTC & Freenode) Web: http://www.practicalsysadmin.com Director, Software in the Public Interest (http://spi-inc.org/) Free & Open Source: The revolution that quietly changed the world "One ought not to believe anything, save that which can be proven by nature and the force of reason" -- Frederick II (26 December 1194 – 13 December 1250)
Colos in Melbourne, FL.
For those with Colo space in Melbourne FL. Please reply to me offlist; looking to deploy a POP there. Thanks. Sent from my HTC on the Now Network from Sprint!
Re: recommendations for external montioring services?
On 12/13/2011 5:11 AM, Michiel Klaver wrote: At 22-07-2011 20:59, Eric J Esslinger wrote: I'm not looking to monitor a massive infrastructure: 3 web sites, 2 mail servers (pop,imap,submission port, https webmail), 4 dns servers (including lookups to ensure they're not listening but not talking), and one inbound mx. A few network points to ping to ensure connectivity throughout my system. Scheduled notification windows (for example, during work hours I don't want my phone pinged unless it's everything going offline. Off hours I do. Secondary notifications if problem persists to other users, or in the event of many triggers. That sort of thing). Sensitivity settings (If web server 1 shows down for 5 min, that's not a big deal. Another one if it doesn't respond to repeated queries within 1 minute is a big deal) A Weekly summary of issues would be nice. (especially the 'well it was down for a short bit but we didn't notify as per settings') I don't have a lot of money to throw at this. I DO have detailed internal monitoring of our systems but sometimes that is not entirely useful, due to the fact that there are a few 'single points of failure' within our network/notification system, not to mention if the monitor itself goes offline it's not exactly going to be able to tell me about it. (and that happened once, right before the mail server decided to stop receiving mail). Some external monitoring services I could recommend: https://circonus.com/ http://mon.itor.us/ http://pingdom.com/ I'll throw another into the list: http://www.watchmouse.com/ They have some nice features and monitoring over IPv4 and IPv6. -DMM
Re: recommendations for external montioring services?
At 22-07-2011 20:59, Eric J Esslinger wrote: > I'm not looking to monitor a massive infrastructure: 3 web sites, 2 mail > servers (pop,imap,submission port, https webmail), 4 dns servers (including > lookups to ensure they're not listening but not talking), and one inbound mx. > A few network points to ping to ensure connectivity throughout my system. > Scheduled notification windows (for example, during work hours I don't want > my phone pinged unless it's everything going offline. Off hours I do. > Secondary notifications if problem persists to other users, or in the event > of many triggers. That sort of thing). Sensitivity settings (If web server 1 > shows down for 5 min, that's not a big deal. Another one if it doesn't > respond to repeated queries within 1 minute is a big deal) A Weekly summary > of issues would be nice. (especially the 'well it was down for a short bit > but we didn't notify as per settings') > I don't have a lot of money to throw at this. I DO have detailed internal > monitoring of our systems but sometimes that is not entirely useful, due to > the fact that there are a few 'single points of failure' within our > network/notification system, not to mention if the monitor itself goes > offline it's not exactly going to be able to tell me about it. (and that > happened once, right before the mail server decided to stop receiving mail). > Some external monitoring services I could recommend: https://circonus.com/ http://mon.itor.us/ http://pingdom.com/
Re: Sad IPv4 story?
On Dec 11, 2011, at 6:52 AM, John Curran wrote: > The sooner we get the content on IPv6 in addition to IPv4, the sooner > that connecting new customers up via IPv6 without additional unique > IPv4 address space becomes viable (and obviously if we had the vast > majority of content already on IPv6, then connecting new customers > via IPv6 would be simple indeed.) Google and other content providers will whitelist you if you coordinate with them. Some may not like the social-political implications of this as it will create what some see as IPv6 islands that are overlays on the global IPv6 network. This is nothing new, there have always been private and policy based decisions that lead to reachability. We have seen great success (IMHO) in IPv6 day. We need to see this happen again with a broader number of networks having IPv6 connectivity. I look forward to seeing the continued broadband deployment of IPv6 to make the data far more interesting. I'm glad to see the major carriers doing IPv6 work in this space. It appears that the traditional/incumbent telcos in the US are behind the curve, but I'm not entirely convinced their business model is relevant in the future decades. - Jared
128.0.0.0/16 as seen from RIPE Atlas
Dear colleagues, As a follow-up to the recent article "The Curious Case of 128.0/16", we now looked at 128.0/16 as seen from RIPE Atlas: https://labs.ripe.net/Members/dfk/128.0-16-seen-by-atlas Kind regards, Mirjam Kuehne RIPE NCC
