Re: Upcoming Improvements to ARIN's Directory Service
On Jun 10, 2010, at 6:16 PM, Jason Lewis wrote: It's very clear. I went back and forth with support, asking how to automate my bulk transfer with the new system. Me: Is the bulk data download going to be available for automated download. I can currently download the data daily from the ftp via a script. The new web page doesn't seem to support that. Support: No, there is no automation by design. I'm ok with whatever system they provide if the functionality stays the same. I don't understand what they gain by making a human login and download the file. Jason - My apologies for the confusion over this when you called in; while we had briefed the support team on RESTful WHOIS, we hadn't covered the updated Bulk Whois interface as it is a bit of a specialized item and coming out on the next release of ARIN Online due to its need for API key support. The 26 June release of ARIN Online will allow you to create and manage these keys, which in turn may be used in RESTful calls (and email templates!) for authentication. A brief overview of this feature was provided at the ARIN Toronto meeting and is available here: https://www.arin.net/participate/meetings/reports/ARIN_XXV/PDF/Tuesday/Newton-REST-and-Relax.pdf We will rollout the API key functionality and Bulk Whois via the RESTful interface with this next release of ARIN Online on 26 June, and this will allow the Bulk Whois data to be downloaded directly without logging into ARIN Online by using a RESTful HTTP request containing your API key. As Mark Kosters noted in his message, we did contact current Bulk Whois users ahead of time about these changes, but if you were missed or have any questions about the change, please don't hesitate to contact myself or Mark directly. Thanks! /John John Curran President and CEO ARIN Begin forwarded message: From: Mark Kosters ma...@arin.net Date: June 11, 2010 3:17:49 PM EDT To: nanog@nanog.org Subject: Re: Upcoming Improvements to ARIN's Directory Service Hi ARIN is making significant improvements to our systems and services. ARIN encourages the community to look for upcoming features as details are available at: https://www.arin.net/features. I would like to clear up the confusion about the changes to access to Bulk Whois that have been discussed in this thread. The next release of ARIN Online on 26 June 2010 will include an easy way of automating bulk Whois reports. ARIN sent an announcement about this change to all current Bulk Whois recipients on 1 June 2010. The current legacy ftp service for Bulk Whois recipients will continue to operate until 31 August 2010. This should allow enough time to make the changes required to your scripts to migrate to the new solution. Regards, Mark Kosters ARIN CTO
Verizon contact
Anyone with a Verizon network engineering contact on the list? There's a bad router/link in Reston, VA for the past 36 hours that we're having a real heck of a time trying to route around. Hoping we can get someone at Verizon to take a look at things. -- Randy
Re: Upcoming Improvements to ARIN's Directory Service
My apologies for the confusion over this when you called in; while we had briefed the support team on RESTful WHOIS, we hadn't covered the updated Bulk Whois interface as it is a bit of a specialized item and coming out on the next release of ARIN Online due to its need for API key support. The 26 June release of ARIN Online will allow you to create and manage these keys, which in turn may be used in RESTful calls (and email templates!) for authentication. A brief overview of this feature was provided at the ARIN Toronto meeting and is available here: https://www.arin.net/participate/meetings/reports/ARIN_XXV/PDF/Tuesday/Newton-REST-and-Relax.pdf We will rollout the API key functionality and Bulk Whois via the RESTful interface with this next release of ARIN Online on 26 June, and this will allow the Bulk Whois data to be downloaded directly without logging into ARIN Online by using a RESTful HTTP request containing your API key. As Mark Kosters noted in his message, we did contact current Bulk Whois users ahead of time about these changes, but if you were missed or have any questions about the change, please don't hesitate to contact myself or Mark directly. john, today, a research batch script running periodic bulk whois work has a line something like ncftpget ftp://user:p...@ftp.arin.net/arin_db.txt.gz well, it can actually be simpler. for the web 9.3 impaired of us, could you describe the simple batch script line under the new improved system? thanks! randy
Re: Upcoming Improvements to ARIN's Directory Service
john, today, a research batch script running periodic bulk whois work has a line something like ncftpget ftp://user:p...@ftp.arin.net/arin_db.txt.gz well, it can actually be simpler. for the web 9.3 impaired of us, could you describe the simple batch script line under the new improved system? Randy - You're going to have to get on ARIN Online at least once to generate an key (this means after June 26), but then accessing the data should be just as simple for a batch script (i.e. use curl or wget for this purpose). I've extracted the relevant draft info from the June 26 release documents and attached below. This is obviously subject to change until the release actually comes out... /John DOWNLOADING USING AN API KEY The report can be downloaded directly without logging into ARIN Online using a RESTful HTTP request containing your API key. The URL must look like: https://www.arin.net/public/rest/downloads/nvpr?apikey=YOUR-API-KEY There are a variety of ways to automate the retrieval of this report. For example, on a Linux system, where your API key is API----, you can use the following 'curl' command to download the report file: curl https://www.arin.net/public/rest/downloads/nvpr?apikey=API---- arin_nvpr.zip You can manage your API keys on the when logged into your ARIN Online account.
Re: Upcoming Improvements to ARIN's Directory Service
You're going to have to get on ARIN Online at least once to generate an key i can probably survive this experience. is there a tee shirt? :) The report can be downloaded directly without logging into ARIN Online using a RESTful HTTP request containing your API key. The URL must look like: https://www.arin.net/public/rest/downloads/nvpr?apikey=YOUR-API-KEY this looks quite doable. thank you! randy
Large number of IPv6 bogons with spoofed ASpath
Hi List Yesterday I noticed a large number of 'bogon' IPv6 announcement. I think it was about a 100 different (IPv6) bogon prefixes [1] [2] being announced from a what looks a variety of origin ASns. Being the administrator of one of these ASns, I'm quite confident that we were not actually announcing this prefix (f006:9000::/24). Looking more carefully at the data. it looks like the Origin AS / ASpaths are spoofed. I suspect it's just one person/organization somewhere in AS174 or AS3257 network which is announcing these bogons prepending it with different ASns. Does anyone have an idea what this could be? Someone doing some kind of an experiment? I summarized my observations here: http://bgpmon.net/blog/?p=299 If anyone has more info about this, please let me know as I am interested to learn more about this. Thanks, Andree [1] http://www.bgpmon.net/showbogons.php?inet=6 [2] http://bit.ly/cH1INE
Re: Large number of IPv6 bogons with spoofed ASpath
On Sat, 12 Jun 2010, Andree Toonk wrote: Hi List Yesterday I noticed a large number of 'bogon' IPv6 announcement. I think it was about a 100 different (IPv6) bogon prefixes [1] [2] being announced from a what looks a variety of origin ASns. I have seen 1000::/32 come in once and a while, but I've noticed that it's hard to catch from where this is coming from. But I've not seen the others. But it does point to the larger lesson that just because it is IPv6, it doesn't mean that prefix-fiters (and other tools) aren't required like in IPv4. wfms
Please report issues with i.root-servers.net
All, Renesys has since a few days had a blog post at http://www.renesys.com/blog/2010/06/two-strikes-i-root.shtml. On the 9th I urged them to provide us with any data if they are seeing incorrect responses from NAY i.root-servers.net instance, and share that with n...@netnod.se. I have so far received a single email from Renesys on friday morning CET time. That email did not contain any data or further information. I asked to share that email with the Nanog list as Renesys will apparently share some results on studies of the i.root-servers.net in Beijing. I have no insight into what these findings, and Renesys did not respond to my request to see them before hand. As of today Renesys have updated their blog post with data that seems to indicate that they have seen incorrect responses from an i.root-servers.net instance. This is the first report of such responses since we re-activated our anycast node in Beijing, and we only saw this by monitoring the comments field to he blog post. At the time of re-activating the node we did test from all locations we could find and queried the i.root-servers.net node in Beijing, and we did not see any incorrect responses. Now, I would request that you all *please* report operational issues with i.root-servers.netm or in case you see any behavior you do not expect to n...@netnod.se. Unfortunately noone from us will attend the upcoming Nanog meeting, and I can't from the agenda see when the presentation is due. I am happy to answer any questions directly though, and I will try and read Renesys results as soon as they are published. In the mean time, as we are dealing what is potentially an operational problem, please report any issues to us. To provide some background, I will share some of my responses to the Renesys email on friday - although I admit they are taken out of context I think they do provide some general background information that might be worth sharing. --- As I wrote in my response to your blogpost, the node in China has ALWAYS been globally reachable (what ever that means. In our terminology it means we are not exporting the prefixes with no-export, so the prefixes propagates as far as our peers advertise them). --- As to the above, many countries tamper with DNS responses so I have no way of assuring anyone that a packet that traverses many countries, many regulations and many networks owners are ever tampered with. In the case where queries to our node in Beijing was seen to respond with incorrect responses, we have obviously been in discussions with our hosts for the node in Beijing and they have as we understand it been in discussions with many of the networks in China. What we understand from these discussions, the occurrence of these incorrect responses for queries sent to i.root-servers.net was a mistake. I have no insight into why or how the mistake happened, but we have been assured it won't be possible for it to happen again. That said - let me again stress that neither we nor anyone else, can assure that packets on the Internet does not get tampered with along the path. What we can do is to deploy mechanisms that will detect this tampering at the application layer, for example DNSSEC. --- Kurt Erik Lindqvist CEO Netnod PGP.sig Description: This is a digitally signed message part
Re: Upcoming Improvements to ARIN's Directory Service
On Jun 12, 2010, at 11:14 AM, Randy Bush wrote: You're going to have to get on ARIN Online at least once to generate an key i can probably survive this experience. is there a tee shirt? :) Your request has been noted... ;-) The report can be downloaded directly without logging into ARIN Online using a RESTful HTTP request containing your API key. The URL must look like: https://www.arin.net/public/rest/downloads/nvpr?apikey=YOUR-API-KEY this looks quite doable. thank you! Thank you (and Jason Lewis!) for pointing out the lack of actionable information regarding this announcement and its impact on Bulk Whois. I've chatted with Mark and Nate on the timing of this service change, and going forward we'll make sure to have replacement services fully deployed and verifiable by the community before announcing an end date for the current service. Thanks again! /John John Curran President and CEO ARIN
On the control of the Internet.
http://volokh.com/2010/06/13/32843/ What happens when the US shuts down part of its part? Depends on what part it shut down, of course. But what are the available boundaries for the parts in question? Will that have to change? For example--what happens when name-service information for a part that is not shutdown comes from a part that is? What if an exchange point for parts that are not shutdown is shutdown. And spare me the tinfoil hat stuff--tinfoil hats have not worked for a year or more. -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
