From brak at gameservers.com  Wed Mar  7 13:20:08 2012
From: brak at gameservers.com (Brian Rak)
Date: Wed, 07 Mar 2012 13:20:08 -0500
Subject: [arin-tech-discuss] Annoyance on ARIN website w/Firefox
Message-ID: <4F57A6D8.9030905@gameservers.com>

It seems the ARIN website forces https (which is good), but whois 
doesn't support https.  So, when you try to use the 'Search WHOIS' box 
in the top right, you get a warning:

'Although this page is encrypted, the information you have entered is to 
be sent over an unencrypted connection and could easily be read by a 
third party.

Are you sure you want to continue sending this information?'

Is this a known issue?  I guess the only fix would be to make whois 
available on https.

- Brian Rak


From brak at gameservers.com  Wed Mar  7 17:20:51 2012
From: brak at gameservers.com (Brian Rak)
Date: Wed, 07 Mar 2012 17:20:51 -0500
Subject: [arin-tech-discuss] Annoyance on ARIN website w/Firefox
In-Reply-To: <2C79FCA006B84D81A70E2804C1AB4809@dp9100>
References: <4F57A6D8.9030905@gameservers.com>
	<2C79FCA006B84D81A70E2804C1AB4809@dp9100>
Message-ID: <4F57DF43.3000204@gameservers.com>

I'm sure it's a known issue, but I thought I'd report it in case somehow 
noone at ARIN had noticed it.  I don't consider disabling firefox's 
warning about this to be a great solution.  The warning is definitely 
legitimate, if I'm on my bank's site and they serve me a https page, but 
the login goes through http for some reason, I definitely want to be 
notified in that case.

There's definitely plenty of workarounds, but that wasn't really what I 
was looking for.  This really only bugs me when I forget to go to 
whois.arin.net instead of arin.net.

On 3/7/2012 5:10 PM, Drake Pallister wrote:
> Hello Brian,
>
> If we're talking about the same thing, this issue is known to me, and 
> therefore probably everyone else in the country.
>
> I don't profess to be an expert on all variations of all browses, But 
> I can show you where this issue is coming from. (If it's what I think 
> you're talking about)
>
> I get that too--sometimes. (when on ARIN's home page) and performing a 
> lookup of an IP /ASN, or whatever. It's just an extra mouse-click 
> added to your day.
>
> The ARIN Form's Submit Action is this: (a non-ssl)
> <form action="http://whois.arin.net/ui/query.do" method="post" 
> name="whois_query" class="whoissearch" id="whois_query">
>
> I'm confident it's a browser based issue, because depending upon what 
> browser I use on which computer. one I.E. doesn't do it and one does. 
> Firefox does depending on how the specific PC's Firefox is set..
>
> I'd think that ARIN probably wants to have that form submit in a 
> non-ssl mode for whatever reason or other. Or maybe this was never 
> asked before. I tend to believe it's because http://whois.arin.net 
> doesn't accept https:// currently.
>
> If you're using Firefox browser, open a URL about:config and scroll 
> down to security.warn_submit_insecure which you can toggle true or 
> false. You can also do the same thing in Firefox's Tools/Options menu.
> However this seems global, for all sites. There's no "Exceptions"  Ah, 
> a suggestion to Firefox!
>
> But anyhow, if you're using Firefox, open up about:config. There is 
> much interesting stuff in there. Also, look for not transmitting the 
> referrer page, which has nothing to do with this subject, but is a 
> concern for many security/privacy-minded Firefox users out there.
>
> I am assuming you're using firefox, but IE works similar.
>
> I hope ARIN doesn't bang me for posting a link, but this Mozilla forum 
> posting shows how to do it step by step from the tools/options menu. 
> http://forums.mozillazine.org/viewtopic.php?f=38&t=665552
>
> If you're doing a lot of lookups then perhaps create a local html page 
> using ARIN's form action.
>
> Or, via a Linux computer/server, from the command line,  run jwhois 
> foo-bar and you'll get decent results. Naturally your Linux machine 
> needs to have jwhois installed. Most distro's do, but it's not hard to 
> install it either.
>
> I have also proven that this problem I believe you're having is due to 
> the "form action" causing a transition from SSL to non-ssl by 
> recreating ARIN's form on a single html page. For now, it works fine 
> either directly from my desktop or from a web server. Take a look at 
> this diagnostic html page and judge for yourself. 
> http://www.duraserver.com/arinsearch.html. Use it to run a search for 
> an IP, ASN, POC, or whatever. They've all worked for me. View the page 
> source code, and copy it to your destop if you believe it doesn't 
> violate ARIN in any way. I doubt if it's a violation of any ARIN reg's 
> because all it really does is pre-enter the information to be looked 
> up and sends it to ARIN, from which you'll receive their whois/RWS 
> lookup pages. It would be sort of like a shortcut if you run it from 
> your desktop. If ARIN doesn't want it called directly from the 
> Internet, then they would likely make use of a http_referrer 
> restriction so it could only be accessed from the locations they decide.
>
> In summary, to get rid of the browser form-submit security warnings 
> from ever happening, then ARIN would need to make the target of the 
> <form action> available via SSL. (Or all browsers would need to allow 
> for specific exemptions for this, on a per-site basis, so you don't 
> have to shut off security settings that you might want when doing 
> online banking, etc.
>
> I hope I have been of help and hope I'm talking about the same problem 
> you are experiencing.
>
> Let me know your findings.
>
> Regards,
> Drake Pallister
>
>
> ----- Original Message ----- From: "Brian Rak" <brak at gameservers.com>
> To: <arin-tech-discuss at arin.net>
> Sent: Wednesday, March 07, 2012 1:20 PM
> Subject: [arin-tech-discuss] Annoyance on ARIN website w/Firefox
>
>
>> It seems the ARIN website forces https (which is good), but whois 
>> doesn't support https.  So, when you try to use the 'Search WHOIS' 
>> box in the top right, you get a warning:
>>
>> 'Although this page is encrypted, the information you have entered is 
>> to be sent over an unencrypted connection and could easily be read by 
>> a third party.
>>
>> Are you sure you want to continue sending this information?'
>>
>> Is this a known issue?  I guess the only fix would be to make whois 
>> available on https.
>>
>> - Brian Rak
>> _______________________________________________
>> arin-tech-discuss mailing list
>> arin-tech-discuss at arin.net
>> http://lists.arin.net/mailman/listinfo/arin-tech-discuss
>>
>
>


From drake.pallister at duraserver.com  Wed Mar  7 17:10:06 2012
From: drake.pallister at duraserver.com (Drake Pallister)
Date: Wed, 7 Mar 2012 17:10:06 -0500
Subject: [arin-tech-discuss] Annoyance on ARIN website w/Firefox
References: <4F57A6D8.9030905@gameservers.com>
Message-ID: <A0271BF7ABED4D6C926465557098C3CC@dp9100>

Hello Brian,

If we're talking about the same thing, this issue is known to me, and 
therefore probably everyone else in the country.

I don't profess to be an expert on all variations of all browses, But I can 
show you where this issue is coming from. (If it's what I think you're 
talking about)

I get that too--sometimes. (when on ARIN's home page) and performing a 
lookup of an IP /ASN, or whatever. It's just an extra mouse-click added to 
your day.

The ARIN Form's Submit Action is this: (a non-ssl)
<form action="http://whois.arin.net/ui/query.do" method="post" 
name="whois_query" class="whoissearch" id="whois_query">

I'm confident it's a browser based issue, because depending upon what 
browser I use on which computer. one I.E. doesn't do it and one does. 
Firefox does depending on how the specific PC's Firefox is set..

I'd think that ARIN probably wants to have that form submit in a non-ssl 
mode for whatever reason or other. Or maybe this was never asked before. I 
tend to believe it's because http://whois.arin.net doesn't accept https:// 
currently.

If you're using Firefox browser, open a URL about:config and scroll down to 
security.warn_submit_insecure which you can toggle true or false. You can 
also do the same thing in Firefox's Tools/Options menu.
However this seems global, for all sites. There's no "Exceptions"  Ah, a 
suggestion to Firefox!

But anyhow, if you're using Firefox, open up about:config. There is much 
interesting stuff in there. Also, look for not transmitting the referrer 
page, which has nothing to do with this subject, but is a concern for many 
security/privacy-minded Firefox users out there.

I am assuming you're using firefox, but IE works similar.

I hope ARIN doesn't bang me for posting a link, but this Mozilla forum 
posting shows how to do it step by step from the tools/options menu. 
http://forums.mozillazine.org/viewtopic.php?f=38&t=665552

If you're doing a lot of lookups then perhaps create a local html page using 
ARIN's form action.

Or, via a Linux computer/server, from the command line,  run jwhois foo-bar 
and you'll get decent results. Naturally your Linux machine needs to have 
jwhois installed. Most distro's do, but it's not hard to install it either.

I have also proven that this problem I believe you're having is due to the 
"form action" causing a transition from SSL to non-ssl by recreating ARIN's 
form on a single html page. For now, it works fine either directly from my 
desktop or from a web server. Take a look at this diagnostic html page and 
judge for yourself. http://www.duraserver.com/arinsearch.html. Use it to run 
a search for an IP, ASN, POC, or whatever. They've all worked for me. View 
the page source code, and copy it to your destop if you believe it doesn't 
violate ARIN in any way. I doubt if it's a violation of any ARIN reg's 
because all it really does is pre-enter the information to be looked up and 
sends it to ARIN, from which you'll receive their whois/RWS lookup pages. It 
would be sort of like a shortcut if you run it from your desktop. If ARIN 
doesn't want it called directly from the Internet, then they would likely 
make use of a http_referrer restriction so it could only be accessed from 
the locations they decide.

In summary, to get rid of the browser form-submit security warnings from 
ever happening, then ARIN would need to make the target of the <form action> 
available via SSL. (Or all browsers would need to allow for specific 
exemptions for this, on a per-site basis, so you don't have to shut off 
security settings that you might want when doing online banking, etc.

I hope I have been of help and hope I'm talking about the same problem you 
are experiencing.

Let me know your findings.

Regards,
Drake Pallister


----- Original Message ----- 
From: "Brian Rak" <brak at gameservers.com>
To: <arin-tech-discuss at arin.net>
Sent: Wednesday, March 07, 2012 1:20 PM
Subject: [arin-tech-discuss] Annoyance on ARIN website w/Firefox


> It seems the ARIN website forces https (which is good), but whois doesn't 
> support https.  So, when you try to use the 'Search WHOIS' box in the top 
> right, you get a warning:
>
> 'Although this page is encrypted, the information you have entered is to 
> be sent over an unencrypted connection and could easily be read by a third 
> party.
>
> Are you sure you want to continue sending this information?'
>
> Is this a known issue?  I guess the only fix would be to make whois 
> available on https.
>
> - Brian Rak
> _______________________________________________
> arin-tech-discuss mailing list
> arin-tech-discuss at arin.net
> http://lists.arin.net/mailman/listinfo/arin-tech-discuss
> 




From drake.pallister at duraserver.com  Wed Mar  7 17:10:20 2012
From: drake.pallister at duraserver.com (Drake Pallister)
Date: Wed, 7 Mar 2012 17:10:20 -0500
Subject: [arin-tech-discuss] Annoyance on ARIN website w/Firefox
References: <4F57A6D8.9030905@gameservers.com>
Message-ID: <2C79FCA006B84D81A70E2804C1AB4809@dp9100>

Hello Brian,

If we're talking about the same thing, this issue is known to me, and 
therefore probably everyone else in the country.

I don't profess to be an expert on all variations of all browses, But I can 
show you where this issue is coming from. (If it's what I think you're 
talking about)

I get that too--sometimes. (when on ARIN's home page) and performing a 
lookup of an IP /ASN, or whatever. It's just an extra mouse-click added to 
your day.

The ARIN Form's Submit Action is this: (a non-ssl)
<form action="http://whois.arin.net/ui/query.do" method="post" 
name="whois_query" class="whoissearch" id="whois_query">

I'm confident it's a browser based issue, because depending upon what 
browser I use on which computer. one I.E. doesn't do it and one does. 
Firefox does depending on how the specific PC's Firefox is set..

I'd think that ARIN probably wants to have that form submit in a non-ssl 
mode for whatever reason or other. Or maybe this was never asked before. I 
tend to believe it's because http://whois.arin.net doesn't accept https:// 
currently.

If you're using Firefox browser, open a URL about:config and scroll down to 
security.warn_submit_insecure which you can toggle true or false. You can 
also do the same thing in Firefox's Tools/Options menu.
However this seems global, for all sites. There's no "Exceptions"  Ah, a 
suggestion to Firefox!

But anyhow, if you're using Firefox, open up about:config. There is much 
interesting stuff in there. Also, look for not transmitting the referrer 
page, which has nothing to do with this subject, but is a concern for many 
security/privacy-minded Firefox users out there.

I am assuming you're using firefox, but IE works similar.

I hope ARIN doesn't bang me for posting a link, but this Mozilla forum 
posting shows how to do it step by step from the tools/options menu. 
http://forums.mozillazine.org/viewtopic.php?f=38&t=665552

If you're doing a lot of lookups then perhaps create a local html page using 
ARIN's form action.

Or, via a Linux computer/server, from the command line,  run jwhois foo-bar 
and you'll get decent results. Naturally your Linux machine needs to have 
jwhois installed. Most distro's do, but it's not hard to install it either.

I have also proven that this problem I believe you're having is due to the 
"form action" causing a transition from SSL to non-ssl by recreating ARIN's 
form on a single html page. For now, it works fine either directly from my 
desktop or from a web server. Take a look at this diagnostic html page and 
judge for yourself. http://www.duraserver.com/arinsearch.html. Use it to run 
a search for an IP, ASN, POC, or whatever. They've all worked for me. View 
the page source code, and copy it to your destop if you believe it doesn't 
violate ARIN in any way. I doubt if it's a violation of any ARIN reg's 
because all it really does is pre-enter the information to be looked up and 
sends it to ARIN, from which you'll receive their whois/RWS lookup pages. It 
would be sort of like a shortcut if you run it from your desktop. If ARIN 
doesn't want it called directly from the Internet, then they would likely 
make use of a http_referrer restriction so it could only be accessed from 
the locations they decide.

In summary, to get rid of the browser form-submit security warnings from 
ever happening, then ARIN would need to make the target of the <form action> 
available via SSL. (Or all browsers would need to allow for specific 
exemptions for this, on a per-site basis, so you don't have to shut off 
security settings that you might want when doing online banking, etc.

I hope I have been of help and hope I'm talking about the same problem you 
are experiencing.

Let me know your findings.

Regards,
Drake Pallister


----- Original Message ----- 
From: "Brian Rak" <brak at gameservers.com>
To: <arin-tech-discuss at arin.net>
Sent: Wednesday, March 07, 2012 1:20 PM
Subject: [arin-tech-discuss] Annoyance on ARIN website w/Firefox


> It seems the ARIN website forces https (which is good), but whois doesn't 
> support https.  So, when you try to use the 'Search WHOIS' box in the top 
> right, you get a warning:
>
> 'Although this page is encrypted, the information you have entered is to 
> be sent over an unencrypted connection and could easily be read by a third 
> party.
>
> Are you sure you want to continue sending this information?'
>
> Is this a known issue?  I guess the only fix would be to make whois 
> available on https.
>
> - Brian Rak
> _______________________________________________
> arin-tech-discuss mailing list
> arin-tech-discuss at arin.net
> http://lists.arin.net/mailman/listinfo/arin-tech-discuss
> 




From markk at arin.net  Fri Mar  9 14:46:59 2012
From: markk at arin.net (Mark Kosters)
Date: Fri, 9 Mar 2012 19:46:59 +0000
Subject: [arin-tech-discuss] Maintenance Notice on the OT&E Registration
	System
Message-ID: <CB7FC860.5FFFE%markk@arin.net>

Hi

On March 13, 2012 from 07:00AM until 9:00AM EST, the OT&E  Registration
System will be down for maintenance. All production services will remain
in operation before, during, and after this maintenance period.

Regards,
Mark Kosters
ARIN CTO



From markk at arin.net  Mon Mar 12 10:16:05 2012
From: markk at arin.net (Mark Kosters)
Date: Mon, 12 Mar 2012 14:16:05 +0000
Subject: [arin-tech-discuss] Annoyance on ARIN website w/Firefox
In-Reply-To: <4F57A6D8.9030905@gameservers.com>
Message-ID: <CB837BE5.60290%markk@arin.net>

Hi Brian

We are planning to deploy whois over https. Our web servers are both
dual-stacked (v4 and v6) and behind load balancers. Based on our load, we
want to offload ssl (https) onto the load balancers - something the load
balancers do a great job in performing. Unfortunately our vendors v6 stack
is not yet quite ready for primetime and we are looking for a stable
version of their code to deploy. Once the load balancer code is stable,
we'll announce https for our whois directory service.

Regards, 
Mark

On 3/7/12 1:20 PM, "Brian Rak" <brak at gameservers.com> wrote:

>It seems the ARIN website forces https (which is good), but whois
>doesn't support https.  So, when you try to use the 'Search WHOIS' box
>in the top right, you get a warning:
>
>'Although this page is encrypted, the information you have entered is to
>be sent over an unencrypted connection and could easily be read by a
>third party.
>
>Are you sure you want to continue sending this information?'
>
>Is this a known issue?  I guess the only fix would be to make whois
>available on https.
>
>- Brian Rak
>_______________________________________________
>arin-tech-discuss mailing list
>arin-tech-discuss at arin.net
>http://lists.arin.net/mailman/listinfo/arin-tech-discuss



From karl.baum at gmail.com  Mon Mar 12 15:39:22 2012
From: karl.baum at gmail.com (Karl Baum)
Date: Mon, 12 Mar 2012 15:39:22 -0400
Subject: [arin-tech-discuss] matching ip addresses to owners of a domain
Message-ID: <AB153BBA-B40B-45C1-B92F-1664C4C4A33B@gmail.com>

I am trying to use the arin api to match ip addresses of our users to certain companies within our database.  For each company I only have a name and domain.  Can i use Arin to associate an ip address with one of the company domains stored within our database?

thx

-karl  

From dhuberma at arin.net  Mon Mar 12 17:14:56 2012
From: dhuberma at arin.net (David Huberman)
Date: Mon, 12 Mar 2012 21:14:56 +0000
Subject: [arin-tech-discuss] matching ip addresses to owners of a domain
In-Reply-To: <AB153BBA-B40B-45C1-B92F-1664C4C4A33B@gmail.com>
Message-ID: <CB83DEDD.DAA3%dhuberma@corp.arin.net>

Karl,

If you have a domain name, you can use our API to discover IP address
registrations ("NETs") associated with POCs who have registered email
addresses in that domain name. There are probably a number of ways to get
from here to there, but here's one solution I came up with:

1) Paragraph 4.4.2 of the document:

https://www.arin.net/resources/whoisrws/whois_api.html#whoisrws

... describes the use of matrix parameters. What we're interested in this
first step is to discover a list of POCs who have email addresses in the
given domain name. If our domain name is washgas.com, for example, we can
query:

http://whois.arin.net/rest/pocs;domain=washgas.com

We get one match, an Ed Rudy from Washington Gas, and it shows us his POC
handle is ERU10-ARIN.

2a) From there, we can search up the hierarchy and ask the API: show me
all organization records ("ORGs") associated with these POCs, so that I
can find NETs that are registered to the ORGs. Why do we ask this? Because
ARIN's Whois is a relational database. NETs are registered to ORGs. ORGs
have POCs who serve various roles (admin, tech, abuse, NOC). So to get to
the NET from the POCs, we have to go via the ORG.

Paragraph 4.4.1 of the documentation shows us how to search for
referential data.  Using our example, we take ERU10-ARIN and ask for all
ORGs it's associated with:

http://whois.arin.net/rest/poc/ERU10-ARIN/orgs

The resulting list has 4 matches, but only 1 unique match: WGL-23, the ORG
defining Washington Gas.


2b) Now we can search for the NETs associated with each of the unique
matches. Using the same methodology, we search for NET data referencing
the ORG. Witness:

http://whois.arin.net/rest/org/WGL-23/nets

The resulting list has 1 IP address registration: NET-208-76-232-0-1

So we can take that and GET:

http://whois.arin.net/rest/net/NET-208-76-232-0-1

.. to programatically discover the starting and ending addresses and/or
the CIDR.


3) Finally, to be complete in our queries, we should search for all NETs
directly associated with these POCs.  That way we capture any NETs that
the POC is a contact on, but for which the POC is not a contact on the
ORG. Using our example one more time:

http://whois.arin.net/rest/poc/ERU10-ARIN/nets

There aren't any matches for ERU10-ARIN, and for most POCs, this result
set will be empty.  But to get a complete picture, you would want to
perform this search anyway.

Hope this answer is helpful for you!

Regards,
David

---
David R Huberman
Principal Technical Analyst, ARIN
703-227-9866



On 3/12/12 3:39 PM, "Karl Baum" <karl.baum at gmail.com> wrote:

I am trying to use the arin api to match ip addresses of our users to
certain companies within our database.  For each company I only have a
name and domain.  Can i use Arin to associate an ip address with one of
the company domains stored within our database?

thx

-karl  
_______________________________________________
arin-tech-discuss mailing list
arin-tech-discuss at arin.net
http://lists.arin.net/mailman/listinfo/arin-tech-discuss







From karl.baum at gmail.com  Mon Mar 12 22:41:06 2012
From: karl.baum at gmail.com (Karl Baum)
Date: Mon, 12 Mar 2012 22:41:06 -0400
Subject: [arin-tech-discuss] matching ip addresses to owners of a domain
In-Reply-To: <CB83DEDD.DAA3%dhuberma@corp.arin.net>
References: <CB83DEDD.DAA3%dhuberma@corp.arin.net>
Message-ID: <6477F88D-986E-4662-B0D2-8D5A499E3041@gmail.com>

This is exactly what i needed.  Thanks David!

Sent from my iPad

On Mar 12, 2012, at 5:14 PM, David Huberman <dhuberma at arin.net> wrote:

> Karl,
> 
> If you have a domain name, you can use our API to discover IP address
> registrations ("NETs") associated with POCs who have registered email
> addresses in that domain name. There are probably a number of ways to get
> from here to there, but here's one solution I came up with:
> 
> 1) Paragraph 4.4.2 of the document:
> 
> https://www.arin.net/resources/whoisrws/whois_api.html#whoisrws
> 
> ... describes the use of matrix parameters. What we're interested in this
> first step is to discover a list of POCs who have email addresses in the
> given domain name. If our domain name is washgas.com, for example, we can
> query:
> 
> http://whois.arin.net/rest/pocs;domain=washgas.com
> 
> We get one match, an Ed Rudy from Washington Gas, and it shows us his POC
> handle is ERU10-ARIN.
> 
> 2a) From there, we can search up the hierarchy and ask the API: show me
> all organization records ("ORGs") associated with these POCs, so that I
> can find NETs that are registered to the ORGs. Why do we ask this? Because
> ARIN's Whois is a relational database. NETs are registered to ORGs. ORGs
> have POCs who serve various roles (admin, tech, abuse, NOC). So to get to
> the NET from the POCs, we have to go via the ORG.
> 
> Paragraph 4.4.1 of the documentation shows us how to search for
> referential data.  Using our example, we take ERU10-ARIN and ask for all
> ORGs it's associated with:
> 
> http://whois.arin.net/rest/poc/ERU10-ARIN/orgs
> 
> The resulting list has 4 matches, but only 1 unique match: WGL-23, the ORG
> defining Washington Gas.
> 
> 
> 2b) Now we can search for the NETs associated with each of the unique
> matches. Using the same methodology, we search for NET data referencing
> the ORG. Witness:
> 
> http://whois.arin.net/rest/org/WGL-23/nets
> 
> The resulting list has 1 IP address registration: NET-208-76-232-0-1
> 
> So we can take that and GET:
> 
> http://whois.arin.net/rest/net/NET-208-76-232-0-1
> 
> .. to programatically discover the starting and ending addresses and/or
> the CIDR.
> 
> 
> 3) Finally, to be complete in our queries, we should search for all NETs
> directly associated with these POCs.  That way we capture any NETs that
> the POC is a contact on, but for which the POC is not a contact on the
> ORG. Using our example one more time:
> 
> http://whois.arin.net/rest/poc/ERU10-ARIN/nets
> 
> There aren't any matches for ERU10-ARIN, and for most POCs, this result
> set will be empty.  But to get a complete picture, you would want to
> perform this search anyway.
> 
> Hope this answer is helpful for you!
> 
> Regards,
> David
> 
> ---
> David R Huberman
> Principal Technical Analyst, ARIN
> 703-227-9866
> 
> 
> 
> On 3/12/12 3:39 PM, "Karl Baum" <karl.baum at gmail.com> wrote:
> 
> I am trying to use the arin api to match ip addresses of our users to
> certain companies within our database.  For each company I only have a
> name and domain.  Can i use Arin to associate an ip address with one of
> the company domains stored within our database?
> 
> thx
> 
> -karl  
> _______________________________________________
> arin-tech-discuss mailing list
> arin-tech-discuss at arin.net
> http://lists.arin.net/mailman/listinfo/arin-tech-discuss
> 
> 
> 
> 
> 


From dhuberma at arin.net  Tue Mar 13 10:31:27 2012
From: dhuberma at arin.net (David Huberman)
Date: Tue, 13 Mar 2012 14:31:27 +0000
Subject: [arin-tech-discuss] matching ip addresses to owners of a domain
In-Reply-To: <6477F88D-986E-4662-B0D2-8D5A499E3041@gmail.com>
References: <CB83DEDD.DAA3%dhuberma@corp.arin.net>,
	<6477F88D-986E-4662-B0D2-8D5A499E3041@gmail.com>
Message-ID: <47BF05778FBAC446B2C9219A3995592413D61724@CHAXCH01.corp.arin.net>

Hi Karl,

You're welcome; glad we could help!  A quick helpful hint:  when using the matrix parameter search for domain names, you want to be careful of false positives.  If we ask:

https://www.arin.net/rest/pocs;domain=arin.net

... we'll get a bunch of arin.net POCs, but we'll also get a false positive:  mandarin.net

Best,
David

---
David R Huberman
Principal Technical Analyst, ARIN
703-227-9866

________________________________________
From: Karl Baum [karl.baum at gmail.com]
Sent: Monday, March 12, 2012 10:41 PM
To: David Huberman
Cc: arin-tech-discuss at arin.net
Subject: Re: [arin-tech-discuss] matching ip addresses to owners of a domain

This is exactly what i needed.  Thanks David!

Sent from my iPad

On Mar 12, 2012, at 5:14 PM, David Huberman <dhuberma at arin.net> wrote:

> Karl,
>
> If you have a domain name, you can use our API to discover IP address
> registrations ("NETs") associated with POCs who have registered email
> addresses in that domain name. There are probably a number of ways to get
> from here to there, but here's one solution I came up with:
>
> 1) Paragraph 4.4.2 of the document:
>
> https://www.arin.net/resources/whoisrws/whois_api.html#whoisrws
>
> ... describes the use of matrix parameters. What we're interested in this
> first step is to discover a list of POCs who have email addresses in the
> given domain name. If our domain name is washgas.com, for example, we can
> query:
>
> http://whois.arin.net/rest/pocs;domain=washgas.com
>
> We get one match, an Ed Rudy from Washington Gas, and it shows us his POC
> handle is ERU10-ARIN.
>
> 2a) From there, we can search up the hierarchy and ask the API: show me
> all organization records ("ORGs") associated with these POCs, so that I
> can find NETs that are registered to the ORGs. Why do we ask this? Because
> ARIN's Whois is a relational database. NETs are registered to ORGs. ORGs
> have POCs who serve various roles (admin, tech, abuse, NOC). So to get to
> the NET from the POCs, we have to go via the ORG.
>
> Paragraph 4.4.1 of the documentation shows us how to search for
> referential data.  Using our example, we take ERU10-ARIN and ask for all
> ORGs it's associated with:
>
> http://whois.arin.net/rest/poc/ERU10-ARIN/orgs
>
> The resulting list has 4 matches, but only 1 unique match: WGL-23, the ORG
> defining Washington Gas.
>
>
> 2b) Now we can search for the NETs associated with each of the unique
> matches. Using the same methodology, we search for NET data referencing
> the ORG. Witness:
>
> http://whois.arin.net/rest/org/WGL-23/nets
>
> The resulting list has 1 IP address registration: NET-208-76-232-0-1
>
> So we can take that and GET:
>
> http://whois.arin.net/rest/net/NET-208-76-232-0-1
>
> .. to programatically discover the starting and ending addresses and/or
> the CIDR.
>
>
> 3) Finally, to be complete in our queries, we should search for all NETs
> directly associated with these POCs.  That way we capture any NETs that
> the POC is a contact on, but for which the POC is not a contact on the
> ORG. Using our example one more time:
>
> http://whois.arin.net/rest/poc/ERU10-ARIN/nets
>
> There aren't any matches for ERU10-ARIN, and for most POCs, this result
> set will be empty.  But to get a complete picture, you would want to
> perform this search anyway.
>
> Hope this answer is helpful for you!
>
> Regards,
> David
>
> ---
> David R Huberman
> Principal Technical Analyst, ARIN
> 703-227-9866
>
>
>
> On 3/12/12 3:39 PM, "Karl Baum" <karl.baum at gmail.com> wrote:
>
> I am trying to use the arin api to match ip addresses of our users to
> certain companies within our database.  For each company I only have a
> name and domain.  Can i use Arin to associate an ip address with one of
> the company domains stored within our database?
>
> thx
>
> -karl
> _______________________________________________
> arin-tech-discuss mailing list
> arin-tech-discuss at arin.net
> http://lists.arin.net/mailman/listinfo/arin-tech-discuss
>
>
>
>
>

From karl.baum at gmail.com  Tue Mar 13 11:04:30 2012
From: karl.baum at gmail.com (Karl Baum)
Date: Tue, 13 Mar 2012 11:04:30 -0400
Subject: [arin-tech-discuss] matching ip addresses to owners of a domain
In-Reply-To: <47BF05778FBAC446B2C9219A3995592413D61724@CHAXCH01.corp.arin.net>
References: <CB83DEDD.DAA3%dhuberma@corp.arin.net>,
	<6477F88D-986E-4662-B0D2-8D5A499E3041@gmail.com>
	<47BF05778FBAC446B2C9219A3995592413D61724@CHAXCH01.corp.arin.net>
Message-ID: <A6AC81B7-BA6B-436A-AD15-F110C4D15843@gmail.com>

Whoah.. good point!  I wouldn't have realized that.

Not sure if this is off topic, but is there a recommended approach to storing these ip ranges locally within your database.  I am using postgres on heroku and i noticed that it has first class support for ip addresses but not ip ranges unfortunately.  Was thinking of just adding a rough for each element within the range, but that's not exactly ideal.

Thanks again!


On Mar 13, 2012, at 10:31 AM, David Huberman wrote:

> Hi Karl,
> 
> You're welcome; glad we could help!  A quick helpful hint:  when using the matrix parameter search for domain names, you want to be careful of false positives.  If we ask:
> 
> https://www.arin.net/rest/pocs;domain=arin.net
> 
> ... we'll get a bunch of arin.net POCs, but we'll also get a false positive:  mandarin.net
> 
> Best,
> David
> 
> ---
> David R Huberman
> Principal Technical Analyst, ARIN
> 703-227-9866
> 
> ________________________________________
> From: Karl Baum [karl.baum at gmail.com]
> Sent: Monday, March 12, 2012 10:41 PM
> To: David Huberman
> Cc: arin-tech-discuss at arin.net
> Subject: Re: [arin-tech-discuss] matching ip addresses to owners of a domain
> 
> This is exactly what i needed.  Thanks David!
> 
> Sent from my iPad
> 
> On Mar 12, 2012, at 5:14 PM, David Huberman <dhuberma at arin.net> wrote:
> 
>> Karl,
>> 
>> If you have a domain name, you can use our API to discover IP address
>> registrations ("NETs") associated with POCs who have registered email
>> addresses in that domain name. There are probably a number of ways to get
>> from here to there, but here's one solution I came up with:
>> 
>> 1) Paragraph 4.4.2 of the document:
>> 
>> https://www.arin.net/resources/whoisrws/whois_api.html#whoisrws
>> 
>> ... describes the use of matrix parameters. What we're interested in this
>> first step is to discover a list of POCs who have email addresses in the
>> given domain name. If our domain name is washgas.com, for example, we can
>> query:
>> 
>> http://whois.arin.net/rest/pocs;domain=washgas.com
>> 
>> We get one match, an Ed Rudy from Washington Gas, and it shows us his POC
>> handle is ERU10-ARIN.
>> 
>> 2a) From there, we can search up the hierarchy and ask the API: show me
>> all organization records ("ORGs") associated with these POCs, so that I
>> can find NETs that are registered to the ORGs. Why do we ask this? Because
>> ARIN's Whois is a relational database. NETs are registered to ORGs. ORGs
>> have POCs who serve various roles (admin, tech, abuse, NOC). So to get to
>> the NET from the POCs, we have to go via the ORG.
>> 
>> Paragraph 4.4.1 of the documentation shows us how to search for
>> referential data.  Using our example, we take ERU10-ARIN and ask for all
>> ORGs it's associated with:
>> 
>> http://whois.arin.net/rest/poc/ERU10-ARIN/orgs
>> 
>> The resulting list has 4 matches, but only 1 unique match: WGL-23, the ORG
>> defining Washington Gas.
>> 
>> 
>> 2b) Now we can search for the NETs associated with each of the unique
>> matches. Using the same methodology, we search for NET data referencing
>> the ORG. Witness:
>> 
>> http://whois.arin.net/rest/org/WGL-23/nets
>> 
>> The resulting list has 1 IP address registration: NET-208-76-232-0-1
>> 
>> So we can take that and GET:
>> 
>> http://whois.arin.net/rest/net/NET-208-76-232-0-1
>> 
>> .. to programatically discover the starting and ending addresses and/or
>> the CIDR.
>> 
>> 
>> 3) Finally, to be complete in our queries, we should search for all NETs
>> directly associated with these POCs.  That way we capture any NETs that
>> the POC is a contact on, but for which the POC is not a contact on the
>> ORG. Using our example one more time:
>> 
>> http://whois.arin.net/rest/poc/ERU10-ARIN/nets
>> 
>> There aren't any matches for ERU10-ARIN, and for most POCs, this result
>> set will be empty.  But to get a complete picture, you would want to
>> perform this search anyway.
>> 
>> Hope this answer is helpful for you!
>> 
>> Regards,
>> David
>> 
>> ---
>> David R Huberman
>> Principal Technical Analyst, ARIN
>> 703-227-9866
>> 
>> 
>> 
>> On 3/12/12 3:39 PM, "Karl Baum" <karl.baum at gmail.com> wrote:
>> 
>> I am trying to use the arin api to match ip addresses of our users to
>> certain companies within our database.  For each company I only have a
>> name and domain.  Can i use Arin to associate an ip address with one of
>> the company domains stored within our database?
>> 
>> thx
>> 
>> -karl
>> _______________________________________________
>> arin-tech-discuss mailing list
>> arin-tech-discuss at arin.net
>> http://lists.arin.net/mailman/listinfo/arin-tech-discuss
>> 
>> 
>> 
>> 



From dhuberma at arin.net  Tue Mar 13 16:23:02 2012
From: dhuberma at arin.net (David Huberman)
Date: Tue, 13 Mar 2012 20:23:02 +0000
Subject: [arin-tech-discuss] matching ip addresses to owners of a domain
In-Reply-To: <A6AC81B7-BA6B-436A-AD15-F110C4D15843@gmail.com>
Message-ID: <CB85241A.E5BF%dhuberma@corp.arin.net>

Hi Karl,

Two things:

1) It turns out you can eliminate the false positives issue: just add the
@ sign to the matrix parameter search:

https://www.arin.net/rest/pocs;domain=@arin.net


2) One of the most common ways to represent an IP address range in a
database is to have two columns: one for the start address, and one for
the end address. Finding an address in the range is then simply a matter
of formulating a query looking for an address greater than the start
addresses and smaller than the end addresses. Care should be taken if the
data types for the columns are strings, as the addresses need to be
zero-padded for proper comparison to work. While this is simple to
engineer, in most databases it does not scale well.

Good luck with your project, and if you have any other REST-related
questions, feel free to ask the list!

Regards,
David

---
David R Huberman
Principal Technical Analyst, ARIN
703-227-9866







On 3/13/12 11:04 AM, "Karl Baum" <karl.baum at gmail.com> wrote:

Whoah.. good point!  I wouldn't have realized that.

Not sure if this is off topic, but is there a recommended approach to
storing these ip ranges locally within your database.  I am using postgres
on heroku and i noticed that it has first class support for ip addresses
but not ip ranges unfortunately.  Was thinking of just adding a rough for
each element within the range, but that's not exactly ideal.

Thanks again!


On Mar 13, 2012, at 10:31 AM, David Huberman wrote:

> Hi Karl,
> 
> You're welcome; glad we could help!  A quick helpful hint:  when using
>the matrix parameter search for domain names, you want to be careful of
>false positives.  If we ask:
> 
> https://www.arin.net/rest/pocs;domain=arin.net
> 
> ... we'll get a bunch of arin.net POCs, but we'll also get a false
>positive:  mandarin.net
> 
> Best,
> David
> 
> ---
> David R Huberman
> Principal Technical Analyst, ARIN
> 703-227-9866
> 
> ________________________________________
> From: Karl Baum [karl.baum at gmail.com]
> Sent: Monday, March 12, 2012 10:41 PM
> To: David Huberman
> Cc: arin-tech-discuss at arin.net
> Subject: Re: [arin-tech-discuss] matching ip addresses to owners of a
>domain
> 
> This is exactly what i needed.  Thanks David!
> 
> Sent from my iPad
> 
> On Mar 12, 2012, at 5:14 PM, David Huberman <dhuberma at arin.net> wrote:
> 
>> Karl,
>> 
>> If you have a domain name, you can use our API to discover IP address
>> registrations ("NETs") associated with POCs who have registered email
>> addresses in that domain name. There are probably a number of ways to
>>get
>> from here to there, but here's one solution I came up with:
>> 
>> 1) Paragraph 4.4.2 of the document:
>> 
>> https://www.arin.net/resources/whoisrws/whois_api.html#whoisrws
>> 
>> ... describes the use of matrix parameters. What we're interested in
>>this
>> first step is to discover a list of POCs who have email addresses in the
>> given domain name. If our domain name is washgas.com, for example, we
>>can
>> query:
>> 
>> http://whois.arin.net/rest/pocs;domain=washgas.com
>> 
>> We get one match, an Ed Rudy from Washington Gas, and it shows us his
>>POC
>> handle is ERU10-ARIN.
>> 
>> 2a) From there, we can search up the hierarchy and ask the API: show me
>> all organization records ("ORGs") associated with these POCs, so that I
>> can find NETs that are registered to the ORGs. Why do we ask this?
>>Because
>> ARIN's Whois is a relational database. NETs are registered to ORGs. ORGs
>> have POCs who serve various roles (admin, tech, abuse, NOC). So to get
>>to
>> the NET from the POCs, we have to go via the ORG.
>> 
>> Paragraph 4.4.1 of the documentation shows us how to search for
>> referential data.  Using our example, we take ERU10-ARIN and ask for all
>> ORGs it's associated with:
>> 
>> http://whois.arin.net/rest/poc/ERU10-ARIN/orgs
>> 
>> The resulting list has 4 matches, but only 1 unique match: WGL-23, the
>>ORG
>> defining Washington Gas.
>> 
>> 
>> 2b) Now we can search for the NETs associated with each of the unique
>> matches. Using the same methodology, we search for NET data referencing
>> the ORG. Witness:
>> 
>> http://whois.arin.net/rest/org/WGL-23/nets
>> 
>> The resulting list has 1 IP address registration: NET-208-76-232-0-1
>> 
>> So we can take that and GET:
>> 
>> http://whois.arin.net/rest/net/NET-208-76-232-0-1
>> 
>> .. to programatically discover the starting and ending addresses and/or
>> the CIDR.
>> 
>> 
>> 3) Finally, to be complete in our queries, we should search for all NETs
>> directly associated with these POCs.  That way we capture any NETs that
>> the POC is a contact on, but for which the POC is not a contact on the
>> ORG. Using our example one more time:
>> 
>> http://whois.arin.net/rest/poc/ERU10-ARIN/nets
>> 
>> There aren't any matches for ERU10-ARIN, and for most POCs, this result
>> set will be empty.  But to get a complete picture, you would want to
>> perform this search anyway.
>> 
>> Hope this answer is helpful for you!
>> 
>> Regards,
>> David
>> 
>> ---
>> David R Huberman
>> Principal Technical Analyst, ARIN
>> 703-227-9866
>> 
>> 
>> 
>> On 3/12/12 3:39 PM, "Karl Baum" <karl.baum at gmail.com> wrote:
>> 
>> I am trying to use the arin api to match ip addresses of our users to
>> certain companies within our database.  For each company I only have a
>> name and domain.  Can i use Arin to associate an ip address with one of
>> the company domains stored within our database?
>> 
>> thx
>> 
>> -karl
>> _______________________________________________
>> arin-tech-discuss mailing list
>> arin-tech-discuss at arin.net
>> http://lists.arin.net/mailman/listinfo/arin-tech-discuss
>> 
>> 
>> 
>> 




From karl.baum at gmail.com  Tue Mar 13 16:42:24 2012
From: karl.baum at gmail.com (Karl Baum)
Date: Tue, 13 Mar 2012 16:42:24 -0400
Subject: [arin-tech-discuss] matching ip addresses to owners of a domain
In-Reply-To: <CB85241A.E5BF%dhuberma@corp.arin.net>
References: <CB85241A.E5BF%dhuberma@corp.arin.net>
Message-ID: <B9531D4F-6615-4DCB-9E0A-C446538AA402@gmail.com>

Very nice tip!  Thanks for your help!

-karl

On Mar 13, 2012, at 4:23 PM, David Huberman wrote:

> Hi Karl,
> 
> Two things:
> 
> 1) It turns out you can eliminate the false positives issue: just add the
> @ sign to the matrix parameter search:
> 
> https://www.arin.net/rest/pocs;domain=@arin.net
> 
> 
> 2) One of the most common ways to represent an IP address range in a
> database is to have two columns: one for the start address, and one for
> the end address. Finding an address in the range is then simply a matter
> of formulating a query looking for an address greater than the start
> addresses and smaller than the end addresses. Care should be taken if the
> data types for the columns are strings, as the addresses need to be
> zero-padded for proper comparison to work. While this is simple to
> engineer, in most databases it does not scale well.
> 
> Good luck with your project, and if you have any other REST-related
> questions, feel free to ask the list!
> 
> Regards,
> David
> 
> ---
> David R Huberman
> Principal Technical Analyst, ARIN
> 703-227-9866
> 
> 
> 
> 
> 
> 
> 
> On 3/13/12 11:04 AM, "Karl Baum" <karl.baum at gmail.com> wrote:
> 
> Whoah.. good point!  I wouldn't have realized that.
> 
> Not sure if this is off topic, but is there a recommended approach to
> storing these ip ranges locally within your database.  I am using postgres
> on heroku and i noticed that it has first class support for ip addresses
> but not ip ranges unfortunately.  Was thinking of just adding a rough for
> each element within the range, but that's not exactly ideal.
> 
> Thanks again!
> 
> 
> On Mar 13, 2012, at 10:31 AM, David Huberman wrote:
> 
>> Hi Karl,
>> 
>> You're welcome; glad we could help!  A quick helpful hint:  when using
>> the matrix parameter search for domain names, you want to be careful of
>> false positives.  If we ask:
>> 
>> https://www.arin.net/rest/pocs;domain=arin.net
>> 
>> ... we'll get a bunch of arin.net POCs, but we'll also get a false
>> positive:  mandarin.net
>> 
>> Best,
>> David
>> 
>> ---
>> David R Huberman
>> Principal Technical Analyst, ARIN
>> 703-227-9866
>> 
>> ________________________________________
>> From: Karl Baum [karl.baum at gmail.com]
>> Sent: Monday, March 12, 2012 10:41 PM
>> To: David Huberman
>> Cc: arin-tech-discuss at arin.net
>> Subject: Re: [arin-tech-discuss] matching ip addresses to owners of a
>> domain
>> 
>> This is exactly what i needed.  Thanks David!
>> 
>> Sent from my iPad
>> 
>> On Mar 12, 2012, at 5:14 PM, David Huberman <dhuberma at arin.net> wrote:
>> 
>>> Karl,
>>> 
>>> If you have a domain name, you can use our API to discover IP address
>>> registrations ("NETs") associated with POCs who have registered email
>>> addresses in that domain name. There are probably a number of ways to
>>> get
>>> from here to there, but here's one solution I came up with:
>>> 
>>> 1) Paragraph 4.4.2 of the document:
>>> 
>>> https://www.arin.net/resources/whoisrws/whois_api.html#whoisrws
>>> 
>>> ... describes the use of matrix parameters. What we're interested in
>>> this
>>> first step is to discover a list of POCs who have email addresses in the
>>> given domain name. If our domain name is washgas.com, for example, we
>>> can
>>> query:
>>> 
>>> http://whois.arin.net/rest/pocs;domain=washgas.com
>>> 
>>> We get one match, an Ed Rudy from Washington Gas, and it shows us his
>>> POC
>>> handle is ERU10-ARIN.
>>> 
>>> 2a) From there, we can search up the hierarchy and ask the API: show me
>>> all organization records ("ORGs") associated with these POCs, so that I
>>> can find NETs that are registered to the ORGs. Why do we ask this?
>>> Because
>>> ARIN's Whois is a relational database. NETs are registered to ORGs. ORGs
>>> have POCs who serve various roles (admin, tech, abuse, NOC). So to get
>>> to
>>> the NET from the POCs, we have to go via the ORG.
>>> 
>>> Paragraph 4.4.1 of the documentation shows us how to search for
>>> referential data.  Using our example, we take ERU10-ARIN and ask for all
>>> ORGs it's associated with:
>>> 
>>> http://whois.arin.net/rest/poc/ERU10-ARIN/orgs
>>> 
>>> The resulting list has 4 matches, but only 1 unique match: WGL-23, the
>>> ORG
>>> defining Washington Gas.
>>> 
>>> 
>>> 2b) Now we can search for the NETs associated with each of the unique
>>> matches. Using the same methodology, we search for NET data referencing
>>> the ORG. Witness:
>>> 
>>> http://whois.arin.net/rest/org/WGL-23/nets
>>> 
>>> The resulting list has 1 IP address registration: NET-208-76-232-0-1
>>> 
>>> So we can take that and GET:
>>> 
>>> http://whois.arin.net/rest/net/NET-208-76-232-0-1
>>> 
>>> .. to programatically discover the starting and ending addresses and/or
>>> the CIDR.
>>> 
>>> 
>>> 3) Finally, to be complete in our queries, we should search for all NETs
>>> directly associated with these POCs.  That way we capture any NETs that
>>> the POC is a contact on, but for which the POC is not a contact on the
>>> ORG. Using our example one more time:
>>> 
>>> http://whois.arin.net/rest/poc/ERU10-ARIN/nets
>>> 
>>> There aren't any matches for ERU10-ARIN, and for most POCs, this result
>>> set will be empty.  But to get a complete picture, you would want to
>>> perform this search anyway.
>>> 
>>> Hope this answer is helpful for you!
>>> 
>>> Regards,
>>> David
>>> 
>>> ---
>>> David R Huberman
>>> Principal Technical Analyst, ARIN
>>> 703-227-9866
>>> 
>>> 
>>> 
>>> On 3/12/12 3:39 PM, "Karl Baum" <karl.baum at gmail.com> wrote:
>>> 
>>> I am trying to use the arin api to match ip addresses of our users to
>>> certain companies within our database.  For each company I only have a
>>> name and domain.  Can i use Arin to associate an ip address with one of
>>> the company domains stored within our database?
>>> 
>>> thx
>>> 
>>> -karl
>>> _______________________________________________
>>> arin-tech-discuss mailing list
>>> arin-tech-discuss at arin.net
>>> http://lists.arin.net/mailman/listinfo/arin-tech-discuss
>>> 
>>> 
>>> 
>>> 
> 
> 



From markk at arin.net  Wed Mar 14 13:37:43 2012
From: markk at arin.net (Mark Kosters)
Date: Wed, 14 Mar 2012 17:37:43 +0000
Subject: [arin-tech-discuss] API Changes to Reg-RWS in OT&E Environment
Message-ID: <CB864F9B.607B1%markk@arin.net>

Hi

ARIN's OT&E environment has been updated with new code on Tuesday, March
13. We anticipate that this code will be rolled out in production on March
24.  This code has introduced additional functionality and the marked-up
version of the payloads and method documents are attached.

If you have an account in ARIN's OT&E Environment, you are welcome to
start exercising the new API.

Regards,
Mark
ARIN CTO

-------------- next part --------------
A non-text attachment was scrubbed...
Name: restful-payloads-March2012.pdf
Type: application/pdf
Size: 322263 bytes
Desc: restful-payloads-March2012.pdf
URL: <https://lists.arin.net/pipermail/arin-tech-discuss/attachments/20120314/9ef40bdc/attachment.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: restful-methods-March2012.pdf
Type: application/pdf
Size: 251562 bytes
Desc: restful-methods-March2012.pdf
URL: <https://lists.arin.net/pipermail/arin-tech-discuss/attachments/20120314/9ef40bdc/attachment-0001.pdf>

From lminer at gmail.com  Thu Mar 15 11:05:52 2012
From: lminer at gmail.com (Luke Miner)
Date: Thu, 15 Mar 2012 15:05:52 +0000
Subject: [arin-tech-discuss] Converting XML to .csv format
Message-ID: <CAG0h4i4QyXdpYXmiu3Gi=DCVobTDv32rsJxV5bT2Uf9+w+cECQ@mail.gmail.com>

I am trying to convert the bulk whois data into csv format so that I can
use it in a statistical package.

For each IP address I'd like to get the list of associated POCs plus the
date of assignment. Something like:
-startAddress, endAddress, orgHandle1, registrationDate1, orgHandle2,
registrationDate2, etc.

Right now I'm importing the NET XML Elements data into Microsoft Access,
and exporting the net table as a csv file. Unfortunately, there are errors
during the import, so, for example, the POC field is empty. Also the CSV
file that I'm left with is disaggregated at the network level, with
overlapping ranges. It's not clear how to get from this to data providing
all the networks associated with a given block of IP addresses.

Any help would be most appreciated,

Thanks,
Luke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-tech-discuss/attachments/20120315/c1e5a3bf/attachment.html>

From dhuberma at arin.net  Thu Mar 15 11:42:52 2012
From: dhuberma at arin.net (David Huberman)
Date: Thu, 15 Mar 2012 15:42:52 +0000
Subject: [arin-tech-discuss] Converting XML to .csv format
In-Reply-To: <CAG0h4i4QyXdpYXmiu3Gi=DCVobTDv32rsJxV5bT2Uf9+w+cECQ@mail.gmail.com>
Message-ID: <CB87802B.10558%dhuberma@corp.arin.net>

Hello Luke,

1) Working with NETS:

I believe you want to look for the parentNetHandle data as the key to
connect the dots. For example, there are three NETs in our database that
contain the IP address 24.0.0.0:

24.0.0.0/8 for OrgID: ARIN.  It has netHandle NET-24-0-0-0-0
24.0.0.0/12 for OrgID: CMCS. It has netHandle NET-24-0-0-0-1 and is
parented by NET-24-0-0-0-0.
24.0.0.0/16 for Customer Org: C01508994. It has a netHandle NET-24-0-0-0-2
and is parented by NET-24-0-0-0-1.

NB: the very top of the hierarchy (the blocks issued by IANA to ARIN for
issuance to our customers, like /8s in IPv4 and /12s and /23s in IPv6)
won't have parentNetHandles, so you may also want to account for that.

2) Associating POCs with NETs:

Writing about NETs, you've indicated: "I'd like to get the list of
associated POCs". I think there are two concepts that you need to know to
accomplish this goal.

- NETs can have POCs. We call them "resource POCs".  A NET can have three
kinds of resources POCs: a TechPOC, an AbusePOC, and/or a NOC POC. But all
these are optional.  In most cases, a NET will not have any resource POC.
So you should see a lot of blank POC fields.

- NETs can be registered to either a customer org handle (which look like
C01508994), or a "real" OrgID (like OrgID: CMCS for Comcast or OrgID:
CITYO-121 for the City of Rockford). The real OrgIDs all have one admin
POC, and at least one tech POC and abuse POC.  They may also have at least
one optional NOC POC.  In contrast, customer orgs do not have POCs at all.

In the easy case, a NET is registered to an OrgID, and we consider the
OrgID's POCs to be the POCs for their NETs.

For example, 216.64.0.0/17 is registered to OrgID: PAET.  The /17 has no
resource POCs.  OrgID: PAET has an admin POC, a tech POC, and an abuse
POC.  By reference, therefore, you can say that 216.64.0.0/17 has the
following associated POCs:
- IP43-ARIN (the admin and tech POC for OrgID: PAET); and
- ABUSE741-ARIN (the abuse POC for OrgID: PAET).

In the harder case, a NET is registered to a customer Org record.  To
associate any POCs with it, you have to go up a level of hierarchy to the
parentNetHandle, identify the OrgID the parentNetHandle is registered to,
and identify its POCs.

For example, 24.0.0.0/16 is registered to customer org record C01508994.
To compile a list of POCs associated with 24.0.0.0/16, you'd go to the
parentNetHandle, NET-24-0-0-0-1, cross over to the OrgID: CMCS, and find
its POCs (NAPO-ARIN and IC161-ARIN).

So that's how ARIN views it, anyway. It's how we construct Whois query
results, in hopes of providing the most useful data possible.

I hope all that helps!

Regards,
David

---
David R Huberman
Principal Technical Analyst, ARIN
703-227-9866







On 3/15/12 11:05 AM, "Luke Miner" <lminer at gmail.com> wrote:

I am trying to convert the bulk whois data into csv format so that I can
use it in a statistical package.
For each IP address I'd like to get the list of associated POCs plus the
date of assignment. Something like:
-startAddress, endAddress, orgHandle1, registrationDate1, orgHandle2,
registrationDate2, etc.


Right now I'm importing the NET XML Elements data into Microsoft Access,
and exporting the net table as a csv file. Unfortunately, there are errors
during the import, so, for example, the POC field is empty. Also the CSV
file that I'm left with is disaggregated at the network level, with
overlapping ranges. It's not clear how to get from this to data providing
all the networks associated with a given block of IP addresses.

Any help would be most appreciated,

Thanks,
Luke
_______________________________________________
arin-tech-discuss mailing list
arin-tech-discuss at arin.net
http://lists.arin.net/mailman/listinfo/arin-tech-discuss



From lminer at gmail.com  Thu Mar 15 12:08:32 2012
From: lminer at gmail.com (Luke Miner)
Date: Thu, 15 Mar 2012 16:08:32 +0000
Subject: [arin-tech-discuss] Converting XML to .csv format
In-Reply-To: <CB87802B.10558%dhuberma@corp.arin.net>
References: <CAG0h4i4QyXdpYXmiu3Gi=DCVobTDv32rsJxV5bT2Uf9+w+cECQ@mail.gmail.com>
	<CB87802B.10558%dhuberma@corp.arin.net>
Message-ID: <CAG0h4i7OwZAu7+3Owc2ppVGOxX-_oDezEk67QDvx0KZUyTsS=g@mail.gmail.com>

Hi David,

Thank you very much for this; it really helps to clear things up!

I think what I'm looking for is orgID for the parent net handle.

So just to be clear with the example below, ARIN is the top level network
just in the sense that it is in charge of administering this IP block. A
subset of these IPs have been assigned to Comcast, and within comcast's
network, a subset is assigned to Comcast Customer Org?

If whois says that 24.0.0.0/8 has been allocated to ARIN in 2001, but
Comcast doesn't register 24.0.0.0/12 until 2003, does this mean that
24.0.0.0/12 probably wasn't in use at least until the date it was assigned
to Comcast?

Thanks
Luke

On Thu, Mar 15, 2012 at 3:42 PM, David Huberman <dhuberma at arin.net> wrote:

> Hello Luke,
>
> 1) Working with NETS:
>
> I believe you want to look for the parentNetHandle data as the key to
> connect the dots. For example, there are three NETs in our database that
> contain the IP address 24.0.0.0:
>
> 24.0.0.0/8 for OrgID: ARIN.  It has netHandle NET-24-0-0-0-0
> 24.0.0.0/12 for OrgID: CMCS. It has netHandle NET-24-0-0-0-1 and is
> parented by NET-24-0-0-0-0.
> 24.0.0.0/16 for Customer Org: C01508994. It has a netHandle NET-24-0-0-0-2
> and is parented by NET-24-0-0-0-1.
>
> NB: the very top of the hierarchy (the blocks issued by IANA to ARIN for
> issuance to our customers, like /8s in IPv4 and /12s and /23s in IPv6)
> won't have parentNetHandles, so you may also want to account for that.
>
> 2) Associating POCs with NETs:
>
> Writing about NETs, you've indicated: "I'd like to get the list of
> associated POCs". I think there are two concepts that you need to know to
> accomplish this goal.
>
> - NETs can have POCs. We call them "resource POCs".  A NET can have three
> kinds of resources POCs: a TechPOC, an AbusePOC, and/or a NOC POC. But all
> these are optional.  In most cases, a NET will not have any resource POC.
> So you should see a lot of blank POC fields.
>
> - NETs can be registered to either a customer org handle (which look like
> C01508994), or a "real" OrgID (like OrgID: CMCS for Comcast or OrgID:
> CITYO-121 for the City of Rockford). The real OrgIDs all have one admin
> POC, and at least one tech POC and abuse POC.  They may also have at least
> one optional NOC POC.  In contrast, customer orgs do not have POCs at all.
>
> In the easy case, a NET is registered to an OrgID, and we consider the
> OrgID's POCs to be the POCs for their NETs.
>
> For example, 216.64.0.0/17 is registered to OrgID: PAET.  The /17 has no
> resource POCs.  OrgID: PAET has an admin POC, a tech POC, and an abuse
> POC.  By reference, therefore, you can say that 216.64.0.0/17 has the
> following associated POCs:
> - IP43-ARIN (the admin and tech POC for OrgID: PAET); and
> - ABUSE741-ARIN (the abuse POC for OrgID: PAET).
>
> In the harder case, a NET is registered to a customer Org record.  To
> associate any POCs with it, you have to go up a level of hierarchy to the
> parentNetHandle, identify the OrgID the parentNetHandle is registered to,
> and identify its POCs.
>
> For example, 24.0.0.0/16 is registered to customer org record C01508994.
> To compile a list of POCs associated with 24.0.0.0/16, you'd go to the
> parentNetHandle, NET-24-0-0-0-1, cross over to the OrgID: CMCS, and find
> its POCs (NAPO-ARIN and IC161-ARIN).
>
> So that's how ARIN views it, anyway. It's how we construct Whois query
> results, in hopes of providing the most useful data possible.
>
> I hope all that helps!
>
> Regards,
> David
>
> ---
> David R Huberman
> Principal Technical Analyst, ARIN
> 703-227-9866
>
>
>
>
>
>
>
> On 3/15/12 11:05 AM, "Luke Miner" <lminer at gmail.com> wrote:
>
> I am trying to convert the bulk whois data into csv format so that I can
> use it in a statistical package.
> For each IP address I'd like to get the list of associated POCs plus the
> date of assignment. Something like:
> -startAddress, endAddress, orgHandle1, registrationDate1, orgHandle2,
> registrationDate2, etc.
>
>
> Right now I'm importing the NET XML Elements data into Microsoft Access,
> and exporting the net table as a csv file. Unfortunately, there are errors
> during the import, so, for example, the POC field is empty. Also the CSV
> file that I'm left with is disaggregated at the network level, with
> overlapping ranges. It's not clear how to get from this to data providing
> all the networks associated with a given block of IP addresses.
>
> Any help would be most appreciated,
>
> Thanks,
> Luke
> _______________________________________________
> arin-tech-discuss mailing list
> arin-tech-discuss at arin.net
> http://lists.arin.net/mailman/listinfo/arin-tech-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-tech-discuss/attachments/20120315/0989bf52/attachment.html>

From dhuberma at arin.net  Thu Mar 15 12:17:56 2012
From: dhuberma at arin.net (David Huberman)
Date: Thu, 15 Mar 2012 16:17:56 +0000
Subject: [arin-tech-discuss] Converting XML to .csv format
In-Reply-To: <CAG0h4i7OwZAu7+3Owc2ppVGOxX-_oDezEk67QDvx0KZUyTsS=g@mail.gmail.com>
Message-ID: <CB878CAA.10665%dhuberma@corp.arin.net>

Hello Luke,

Glad we could help! You asked:

> So just to be clear with the example below, ARIN is the
> top level network just in the sense that it is in charge
> of administering this IP block. A subset of these IPs
> have been assigned to Comcast, and within comcast's
> network, a subset is assigned to Comcast Customer Org?


Exactly.  And in other examples, it will be ARIN -> OrgID1 -> OrgID2 where
OrgID1 is ARIN's customer (Comcast) and OrgID2 is Comcast's customer
(David & Luke Consulting Co.).  ISPs who sub-delegate IP address blocks to
their customers in ARIN's Whois will sometimes use customer org records,
and sometimes use OrgIDs for their customers.

You wrote:

> If whois says that 24.0.0.0/8 has been allocated to ARIN
> in 2001, but Comcast doesn't register 24.0.0.0/12 until
> 2003, does this mean that 24.0.0.0/12 probably wasn't in
> use at least until the date it was assigned to Comcast?

It depends. 

Sometimes, ARIN assigns our customer an IP address block that has never
previously been assigned. Right now, for example, we're issuing some
blocks out of 100.0.0.0/8.  That's a new /8, and the registrants of space
in that /8 are the very first registrants.

But ARIN also recycles space.  Folks return space to us when they're done
with it, and we re-issue it to a new customer.  Folks also go out of
business, and we revoke the space when they don't pay their bills, and we
re-issue the space to a new customer.  Sometimes we reclaim space due to
fraud being committed. That space also gets re-issed to new customers.

In the example, Comcast was not the original registrant of 24.0.0.0/12.
The beginning of the block was first issued in December 1995 to @Home
Network, Milo Medin's cable internet company from way back in the day.
The bulk Whois data does not provide this data, however.  Bulk Whois is a
snapshot of how Whois looks on the day the data is downloaded.

Regards,
David

---
David R Huberman
Principal Technical Analyst, ARIN
703-227-9866






From droisman at softlayer.com  Wed Mar 28 13:46:45 2012
From: droisman at softlayer.com (Dani Roisman)
Date: Wed, 28 Mar 2012 17:46:45 +0000
Subject: [arin-tech-discuss] zero-padded IP addresses in "startAddress" and
	"endAddress" values
Message-ID: <C40B18ECB19B374EBB7B033835339F1D6E7ADA04@SM-DAG152.softlayer.local>

Greetings,

One of our developers just pointed out to me that the values for "startAddress" and "endAddress" values are now zero padded.  Is it possible this was a result of the Mar 24th code push (http://lists.arin.net/pipermail/arin-tech-discuss/2012-March/000187.html)?  If so - was this expected, or a bug?

Here's an example from query "curl -4 https://www.arin.net/rest/net/NET-75-126-0-0-1?apikey=<snip>" (note, the API key must be authorized to the network owner if you're trying to reproduce this, try your key and your netblock)


<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<net xmlns="http://www.arin.net/regrws/core/v1">
<pocLinks>
<pocLinkRef handle="IPADM258-ARIN" function="N" description="NOC"/>
<pocLinkRef handle="IPADM258-ARIN" function="T" description="Tech"/>
<pocLinkRef handle="ABUSE1025-ARIN" function="AB" description="Abuse"/>
</pocLinks>
<netBlocks>
<netBlock>
<cidrLength>16</cidrLength>
<description>Direct Allocation</description>
<endAddress>075.126.255.255</endAddress>    <--- this line
<startAddress>075.126.000.000</startAddress>    <--- and this line
<type>DA</type>
</netBlock>
</netBlocks>
<handle>NET-75-126-0-0-1</handle>
<netName>SOFTLAYER-4-3</netName>
<orgHandle>SOFTL</orgHandle>
<originASes>
<originAS>AS36351</originAS>
</originASes>
<parentNetHandle>NET-75-0-0-0-0</parentNetHandle>
<registrationDate >2006-05-12T17:11:04-04:00</registrationDate>
<version>4</version>
</net>

Note that this *differs* from public whois output, for example that same netblock:

Using " curl -4 http://whois.arin.net/rest/net/NET-75-126-0-0-1"

<?xml version='1.0'?>
<?xml-stylesheet type='text/xsl' href='http://whois.arin.net/xsl/website.xsl' ?>
<net xmlns="http://www.arin.net/whoisrws/core/v1" xmlns:ns2="http://www.arin.net/whoisrws/rdns/v1" xmlns:ns3="http://www.arin.net/whoisrws/netref/v2" termsOfUse="https://www.arin.net/whois_tou.html">
<registrationDate>2006-05-12T17:11:04-04:00</registrationDate>
<ref>http://whois.arin.net/rest/net/NET-75-126-0-0-1</ref>
<endAddress>75.126.255.255</endAddress>
<handle>NET-75-126-0-0-1</handle>
<name>SOFTLAYER-4-3</name>
<netBlocks>
<netBlock>
<cidrLength>16</cidrLength>
<endAddress>75.126.255.255</endAddress> <-- this is what is expected
<description>Direct Allocation</description>
<type>DA</type>
<startAddress>75.126.0.0</startAddress>  <-- this is what is expected
</netBlock>
</netBlocks>
<originASes><originAS>AS36351</originAS></originASes>
<orgRef name="SoftLayer Technologies Inc." handle="SOFTL">http://whois.arin.net/rest/org/SOFTL</orgRef>
<parentNetRef name="NET75" handle="NET-75-0-0-0-0">http://whois.arin.net/rest/net/NET-75-0-0-0-0</parentNetRef>
<startAddress>75.126.0.0</startAddress>
<updateDate>2012-03-09T11:55:23-05:00</updateDate>
<version>4
</version>
</net>

----
Dani Roisman
VP, Network Operations
droisman at softlayer.com
(281) 714-3714 direct 
(818) 481-5581 cell



From dhuberma at arin.net  Wed Mar 28 15:40:20 2012
From: dhuberma at arin.net (David Huberman)
Date: Wed, 28 Mar 2012 19:40:20 +0000
Subject: [arin-tech-discuss] zero-padded IP addresses in "startAddress"
 and "endAddress" values
In-Reply-To: <C40B18ECB19B374EBB7B033835339F1D6E7ADA04@SM-DAG152.softlayer.local>
Message-ID: <CB98E0A0.12343%dhuberma@corp.arin.net>

Hello Dani,

ARIN's Registration RESTful web service has always expressed IP addresses
with zero padding. As you point out, however, the Whois RESTful web
service does not.  I think a fair explanation of these two behaviors is
that Whois is assumed to be read mostly by humans, and in contrast, the
output of the Registration RESTful web service is assumed to be
interpreted by machines.

We do note that the Payloads documentation currently available does not
properly indicate that the output is zero padded. We have a documentation
refresh coming very very shortly, and we will work to correct this
immediately.

Regards,
David

---
David R Huberman
Principal Technical Analyst, ARIN
703-227-9866







On 3/28/12 1:46 PM, "Dani Roisman" <droisman at softlayer.com> wrote:

Greetings,

One of our developers just pointed out to me that the values for
"startAddress" and "endAddress" values are now zero padded.  Is it
possible this was a result of the Mar 24th code push
(http://lists.arin.net/pipermail/arin-tech-discuss/2012-March/000187.html)?
  If so - was this expected, or a bug?

Here's an example from query "curl -4
https://www.arin.net/rest/net/NET-75-126-0-0-1?apikey=<snip>" (note, the
API key must be authorized to the network owner if you're trying to
reproduce this, try your key and your netblock)


<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<net xmlns="http://www.arin.net/regrws/core/v1">
<pocLinks>
<pocLinkRef handle="IPADM258-ARIN" function="N" description="NOC"/>
<pocLinkRef handle="IPADM258-ARIN" function="T" description="Tech"/>
<pocLinkRef handle="ABUSE1025-ARIN" function="AB" description="Abuse"/>
</pocLinks>
<netBlocks>
<netBlock>
<cidrLength>16</cidrLength>
<description>Direct Allocation</description>
<endAddress>075.126.255.255</endAddress>    <--- this line
<startAddress>075.126.000.000</startAddress>    <--- and this line
<type>DA</type>
</netBlock>
</netBlocks>
<handle>NET-75-126-0-0-1</handle>
<netName>SOFTLAYER-4-3</netName>
<orgHandle>SOFTL</orgHandle>
<originASes>
<originAS>AS36351</originAS>
</originASes>
<parentNetHandle>NET-75-0-0-0-0</parentNetHandle>
<registrationDate >2006-05-12T17:11:04-04:00</registrationDate>
<version>4</version>
</net>

Note that this *differs* from public whois output, for example that same
netblock:

Using " curl -4 http://whois.arin.net/rest/net/NET-75-126-0-0-1"

<?xml version='1.0'?>
<?xml-stylesheet type='text/xsl'
href='http://whois.arin.net/xsl/website.xsl' ?>
<net xmlns="http://www.arin.net/whoisrws/core/v1"
xmlns:ns2="http://www.arin.net/whoisrws/rdns/v1"
xmlns:ns3="http://www.arin.net/whoisrws/netref/v2"
termsOfUse="https://www.arin.net/whois_tou.html">
<registrationDate>2006-05-12T17:11:04-04:00</registrationDate>
<ref>http://whois.arin.net/rest/net/NET-75-126-0-0-1</ref>
<endAddress>75.126.255.255</endAddress>
<handle>NET-75-126-0-0-1</handle>
<name>SOFTLAYER-4-3</name>
<netBlocks>
<netBlock>
<cidrLength>16</cidrLength>
<endAddress>75.126.255.255</endAddress> <-- this is what is expected
<description>Direct Allocation</description>
<type>DA</type>
<startAddress>75.126.0.0</startAddress>  <-- this is what is expected
</netBlock>
</netBlocks>
<originASes><originAS>AS36351</originAS></originASes>
<orgRef name="SoftLayer Technologies Inc."
handle="SOFTL">http://whois.arin.net/rest/org/SOFTL</orgRef>
<parentNetRef name="NET75"
handle="NET-75-0-0-0-0">http://whois.arin.net/rest/net/NET-75-0-0-0-0</pare
ntNetRef>
<startAddress>75.126.0.0</startAddress>
<updateDate>2012-03-09T11:55:23-05:00</updateDate>
<version>4
</version>
</net>

----
Dani Roisman
VP, Network Operations
droisman at softlayer.com
(281) 714-3714 direct
(818) 481-5581 cell

_______________________________________________
arin-tech-discuss mailing list
arin-tech-discuss at arin.net
http://lists.arin.net/mailman/listinfo/arin-tech-discuss



From sethm at rollernet.us  Wed Mar 28 16:17:40 2012
From: sethm at rollernet.us (Seth Mattinen)
Date: Wed, 28 Mar 2012 13:17:40 -0700
Subject: [arin-tech-discuss] zero-padded IP addresses in "startAddress"
 and "endAddress" values
In-Reply-To: <CB98E0A0.12343%dhuberma@corp.arin.net>
References: <CB98E0A0.12343%dhuberma@corp.arin.net>
Message-ID: <4F7371E4.3050504@rollernet.us>

On 3/28/12 12:40 PM, David Huberman wrote:
> Hello Dani,
> 
> ARIN's Registration RESTful web service has always expressed IP addresses
> with zero padding. As you point out, however, the Whois RESTful web
> service does not.  I think a fair explanation of these two behaviors is
> that Whois is assumed to be read mostly by humans, and in contrast, the
> output of the Registration RESTful web service is assumed to be
> interpreted by machines.
> 

I find that logic flawed; leading zeros can mean "octal" to machines. If
indeed the output is assumed to be interpreted be machines as octal then
leading zeros would be appropriate, whereas a human would normally read
a zero-padded number as base 10. If you're going to zero-pad then for
consistency you should return "075.0126.000.000" rather than an
ambiguous mix of potentially octal and potentially base 10. Or simply
don't zero pad without a technical basis.

For example, if I were to take that output and feed it into "ping" on
any of my Linux servers they do indeed interpret 075 as octal and try to
ping "61.126.0.0".

~Seth



From aaronh at bind.com  Wed Mar 28 16:38:41 2012
From: aaronh at bind.com (Aaron Hughes)
Date: Wed, 28 Mar 2012 13:38:41 -0700
Subject: [arin-tech-discuss] zero-padded IP addresses in "startAddress"
 and "endAddress" values
In-Reply-To: <4F7371E4.3050504@rollernet.us>
References: <CB98E0A0.12343%dhuberma@corp.arin.net>
	<4F7371E4.3050504@rollernet.us>
Message-ID: <20120328203841.GA36731@trace.bind.com>

+1

Thanks Seth.

Cheers,
Aaron

On Wed, Mar 28, 2012 at 01:17:40PM -0700, Seth Mattinen wrote:
> On 3/28/12 12:40 PM, David Huberman wrote:
> > Hello Dani,
> > 
> > ARIN's Registration RESTful web service has always expressed IP addresses
> > with zero padding. As you point out, however, the Whois RESTful web
> > service does not.  I think a fair explanation of these two behaviors is
> > that Whois is assumed to be read mostly by humans, and in contrast, the
> > output of the Registration RESTful web service is assumed to be
> > interpreted by machines.
> > 
> 
> I find that logic flawed; leading zeros can mean "octal" to machines. If
> indeed the output is assumed to be interpreted be machines as octal then
> leading zeros would be appropriate, whereas a human would normally read
> a zero-padded number as base 10. If you're going to zero-pad then for
> consistency you should return "075.0126.000.000" rather than an
> ambiguous mix of potentially octal and potentially base 10. Or simply
> don't zero pad without a technical basis.
> 
> For example, if I were to take that output and feed it into "ping" on
> any of my Linux servers they do indeed interpret 075 as octal and try to
> ping "61.126.0.0".
> 
> ~Seth
> 
> -- 
> arin-tech-discuss mailing list
> arin-tech-discuss at arin.net
> http://lists.arin.net/mailman/listinfo/arin-tech-discuss

-- 

Aaron Hughes 
aaronh at bind.com
+1-831-824-4161
Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8
http://www.bind.com/


From andy at arin.net  Thu Mar 29 09:56:57 2012
From: andy at arin.net (Andy Newton)
Date: Thu, 29 Mar 2012 13:56:57 +0000
Subject: [arin-tech-discuss] zero-padded IP addresses in "startAddress"
 and "endAddress" values
In-Reply-To: <4F7371E4.3050504@rollernet.us>
References: <CB98E0A0.12343%dhuberma@corp.arin.net>
	<4F7371E4.3050504@rollernet.us>
Message-ID: <A236635F-0749-4DF0-928C-8B8D8C43A16E@arin.net>


On Mar 28, 2012, at 10:17 PM, Seth Mattinen wrote:

> On 3/28/12 12:40 PM, David Huberman wrote:
>> Hello Dani,
>> 
>> ARIN's Registration RESTful web service has always expressed IP addresses
>> with zero padding. As you point out, however, the Whois RESTful web
>> service does not.  I think a fair explanation of these two behaviors is
>> that Whois is assumed to be read mostly by humans, and in contrast, the
>> output of the Registration RESTful web service is assumed to be
>> interpreted by machines.
>> 
> 
> I find that logic flawed; leading zeros can mean "octal" to machines. If
> indeed the output is assumed to be interpreted be machines as octal then
> leading zeros would be appropriate, whereas a human would normally read
> a zero-padded number as base 10. If you're going to zero-pad then for
> consistency you should return "075.0126.000.000" rather than an
> ambiguous mix of potentially octal and potentially base 10. Or simply
> don't zero pad without a technical basis.
> 
> For example, if I were to take that output and feed it into "ping" on
> any of my Linux servers they do indeed interpret 075 as octal and try to
> ping "61.126.0.0".

Seth,

Let me offer the technical basis you are asking for.

Zero padding IP addresses is useful for comparing IP addresses to each other as strings. Many languages and most databases do not have IP address data types, so zero padding enables easy comparison via string methods found in all languages and databases. This is particularly useful for determining if an IP address is greater than a starting address and less than an ending address, which is an easy approach for using a database to store IP address ranges and determining if a given IP address falls within that range.

That is what David is meaning when he says the data from Reg-RWS is to be interpreted by machines.

Is this helpful information?

Andy Newton,
Chief Engineer, ARIN



From karl.baum at gmail.com  Thu Mar 29 16:21:09 2012
From: karl.baum at gmail.com (Karl Baum)
Date: Thu, 29 Mar 2012 16:21:09 -0400
Subject: [arin-tech-discuss] mapping ip addresses to domains
Message-ID: <5A8EE213-C531-4648-9214-D9FAE458D954@gmail.com>

If i have an ip address, many times i can map that ip to email domains by jumping from ip to org to pocs.  The problem i run into is that many times the ip is not associated with an org but instead a customer.  For example:

https://gist.github.com/9429c3683719eff115fb

Is there a way to get to the pocs in this case?

thx!

-karl

From dhuberma at arin.net  Thu Mar 29 17:14:36 2012
From: dhuberma at arin.net (David Huberman)
Date: Thu, 29 Mar 2012 21:14:36 +0000
Subject: [arin-tech-discuss] mapping ip addresses to domains
In-Reply-To: <5A8EE213-C531-4648-9214-D9FAE458D954@gmail.com>
Message-ID: <CB9A483F.123A1%dhuberma@corp.arin.net>

Hiya Karl,

Service providers have the option of registering reassignments either with
or without customer POC information.  In the cases when they choose not to
publish customer POC information (and thus the network is associated with
a customer ID rather than an Org ID), there's not enough data provided to
connect an IP address range with a possibly-associated domain.

Regards,
David

---
David R Huberman
Principal Technical Analyst, ARIN
703-227-9866







On 3/29/12 4:21 PM, "Karl Baum" <karl.baum at gmail.com> wrote:

If i have an ip address, many times i can map that ip to email domains by
jumping from ip to org to pocs.  The problem i run into is that many times
the ip is not associated with an org but instead a customer.  For example:

https://gist.github.com/9429c3683719eff115fb

Is there a way to get to the pocs in this case?

thx!

-karl
_______________________________________________
arin-tech-discuss mailing list
arin-tech-discuss at arin.net
http://lists.arin.net/mailman/listinfo/arin-tech-discuss



From sethm at rollernet.us  Thu Mar 29 22:06:49 2012
From: sethm at rollernet.us (Seth Mattinen)
Date: Thu, 29 Mar 2012 19:06:49 -0700
Subject: [arin-tech-discuss] zero-padded IP addresses in "startAddress"
 and "endAddress" values
In-Reply-To: <A236635F-0749-4DF0-928C-8B8D8C43A16E@arin.net>
References: <CB98E0A0.12343%dhuberma@corp.arin.net>
	<4F7371E4.3050504@rollernet.us>
	<A236635F-0749-4DF0-928C-8B8D8C43A16E@arin.net>
Message-ID: <4F751539.20809@rollernet.us>

On 3/29/12 6:56 AM, Andy Newton wrote:
> 
> On Mar 28, 2012, at 10:17 PM, Seth Mattinen wrote:
> 
>> On 3/28/12 12:40 PM, David Huberman wrote:
>>> Hello Dani,
>>>
>>> ARIN's Registration RESTful web service has always expressed IP addresses
>>> with zero padding. As you point out, however, the Whois RESTful web
>>> service does not.  I think a fair explanation of these two behaviors is
>>> that Whois is assumed to be read mostly by humans, and in contrast, the
>>> output of the Registration RESTful web service is assumed to be
>>> interpreted by machines.
>>>
>>
>> I find that logic flawed; leading zeros can mean "octal" to machines. If
>> indeed the output is assumed to be interpreted be machines as octal then
>> leading zeros would be appropriate, whereas a human would normally read
>> a zero-padded number as base 10. If you're going to zero-pad then for
>> consistency you should return "075.0126.000.000" rather than an
>> ambiguous mix of potentially octal and potentially base 10. Or simply
>> don't zero pad without a technical basis.
>>
>> For example, if I were to take that output and feed it into "ping" on
>> any of my Linux servers they do indeed interpret 075 as octal and try to
>> ping "61.126.0.0".
> 
> Seth,
> 
> Let me offer the technical basis you are asking for.
> 
> Zero padding IP addresses is useful for comparing IP addresses to each other as strings. Many languages and most databases do not have IP address data types, so zero padding enables easy comparison via string methods found in all languages and databases. This is particularly useful for determining if an IP address is greater than a starting address and less than an ending address, which is an easy approach for using a database to store IP address ranges and determining if a given IP address falls within that range.
> 
> That is what David is meaning when he says the data from Reg-RWS is to be interpreted by machines.
> 
> Is this helpful information?
> 


I personally treat IP addresses as unsigned integers (or double/float
for IPv6). It never occurred to me to treat an IP as a string since it's
supposed to represent a 32-bit or 128-bit number. Integer comparisons
are, IMO, easier.

~Seth



From mysidia at gmail.com  Thu Mar 29 23:20:09 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Thu, 29 Mar 2012 22:20:09 -0500
Subject: [arin-tech-discuss] zero-padded IP addresses in "startAddress"
 and "endAddress" values
In-Reply-To: <A236635F-0749-4DF0-928C-8B8D8C43A16E@arin.net>
References: <CB98E0A0.12343%dhuberma@corp.arin.net>
	<4F7371E4.3050504@rollernet.us>
	<A236635F-0749-4DF0-928C-8B8D8C43A16E@arin.net>
Message-ID: <CAAAwwbWksepHP6ghgsp5CGMOGNyFGx=wmPhRv-AFA0-X+waScQ@mail.gmail.com>

On Thu, Mar 29, 2012 at 8:56 AM, Andy Newton <andy at arin.net> wrote:

I would say that ad-hoc textual representation is dangerous when
presented in an API for remote use,  because it visually _resembles_
an IP so closely that it may confuse a human into thinking it is a
valid IP address,   but  the leading zeros make it non-compliant with
the standard representation of an IP address;   the result is
ill-defined, and the octal interpretation is very common.

The leading zeros make the IP addresses unparseable by standard APIs.
I'll give you a  "padded" string has its uses,  but that should be the
responsibility of the application,
and it makes sense to omit the dots in that case to avoid any confusion.

Interoperability with applications utilizing standard APIs should also
be preferred over supporting hacks to facilitate programming in
languages that lack them.


Remote interfaces should utilize the standard representation of IP
addresses,  either the standard textual representation of an IP
address,   or an  internal format that won't likely lead to confusion
or errors, such as the decimal IP address in network byte order.

The  "zero padding"  is non-standard  and    results in something that
cannot be parsed so well with standard APIs for interpreting IP
addresses.


For example,
   "012.020.030.040"   actually  indicates the IP address "10.16.24.32"

[root at orb1 ~ ]# ping -c 5 012.020.030.040
PING 012.020.030.040 (10.16.24.32) 56(84) bytes of data.
                                        ^^^^^^^^^^^


^C
cat <<END > blah.c
>#include <stdio.h>
>#include <arpa/inet.h>
>
>int main()
>{
>    char* input = "012.020.030.040";    struct in_addr address;
>
>    if ( inet_aton(input, &address) != -1) {
>       printf("%s == %s == %d == %X\n", input, inet_ntoa(address), htonl(address.s_addr), >htonl(address.s_addr));
>    }
>}
END
$ ./blah
012.020.030.040 == 10.16.24.32 == 168826912 == A101820
$



>
> Seth,
>
> Let me offer the technical basis you are asking for.
>
> Zero padding IP addresses is useful for comparing IP addresses to each other as strings. Many languages and most databases do not have IP address data types, so zero padding enables easy comparison via string methods found in all languages and databases. This is particularly useful for determining if an IP address is greater than a starting address and less than an ending address, which is an easy approach for using a database to store IP address ranges and determining if a given IP address falls within that range.
>
> That is what David is meaning when he says the data from Reg-RWS is to be interpreted by machines.
>
> Is this helpful information?
>
> Andy Newton,
> Chief Engineer, ARIN
>
> _______________________________________________
> arin-tech-discuss mailing list
> arin-tech-discuss at arin.net
> http://lists.arin.net/mailman/listinfo/arin-tech-discuss



-- 
-JH


From andy at arin.net  Fri Mar 30 08:54:14 2012
From: andy at arin.net (Andy Newton)
Date: Fri, 30 Mar 2012 12:54:14 +0000
Subject: [arin-tech-discuss] zero-padded IP addresses in "startAddress"
 and "endAddress" values
In-Reply-To: <4F751539.20809@rollernet.us>
References: <CB98E0A0.12343%dhuberma@corp.arin.net>
	<4F7371E4.3050504@rollernet.us>
	<A236635F-0749-4DF0-928C-8B8D8C43A16E@arin.net>
	<4F751539.20809@rollernet.us>
Message-ID: <B1E69E62-24FC-4F45-B3C9-48942AADF1C0@arin.net>


On Mar 30, 2012, at 4:06 AM, Seth Mattinen wrote:

> I personally treat IP addresses as unsigned integers (or double/float
> for IPv6). It never occurred to me to treat an IP as a string since it's
> supposed to represent a 32-bit or 128-bit number. Integer comparisons
> are, IMO, easier.

Seth,

Interpretation of IP addresses as numbers makes complete sense. But I will note that some languages do not have unsigned integers and double and float on many platforms, languages, and databases are only 64 bits. Float can be particularly troublesome as IEEE 754 interpretations of it only give 56 bits of precision.

Comparison as a numeric type is also natural, but in a database where an IP address column is indexed that difference is only important for an r-tree index which are not very common. Additionally in a database context, substring matching can be used for prefix queries, though admittedly only on octet boundaries.

Like you, my first inclination as a programmer is to treat IP addresses as numbers. And when I first encountered the usage of zero-padded IP address strings, doing so had never occurred to me. That being said, in my career ARIN is not the first place I have seen this, and in the ARIN codebases we have found this pattern many times, implemented by multiple coders in many subsystems, going back to code that well predates ARIN.

That long-winded explanation aside, we can certainly take steps to make programming against the Reg-RWS interface easier if the community desires. New elements can be added that do not have the zero-padded IP addresses. I do not recommend modifying the current elements as we may break code that counts on the zero padding. And, as David stated, we should update our documentation. Would adding new elements containing IP addresses that are not zero-padded be helpful?

Andy Newton

From andy at arin.net  Fri Mar 30 08:54:24 2012
From: andy at arin.net (Andy Newton)
Date: Fri, 30 Mar 2012 12:54:24 +0000
Subject: [arin-tech-discuss] zero-padded IP addresses in "startAddress"
 and "endAddress" values
In-Reply-To: <CAAAwwbWksepHP6ghgsp5CGMOGNyFGx=wmPhRv-AFA0-X+waScQ@mail.gmail.com>
References: <CB98E0A0.12343%dhuberma@corp.arin.net>
	<4F7371E4.3050504@rollernet.us>
	<A236635F-0749-4DF0-928C-8B8D8C43A16E@arin.net>
	<CAAAwwbWksepHP6ghgsp5CGMOGNyFGx=wmPhRv-AFA0-X+waScQ@mail.gmail.com>
Message-ID: <6699D0A9-4BE2-4240-BE35-8B48A5B1308D@arin.net>


On Mar 30, 2012, at 5:20 AM, Jimmy Hess wrote:

> I would say that ad-hoc textual representation is dangerous when
> presented in an API for remote use,  because it visually _resembles_
> an IP so closely that it may confuse a human into thinking it is a
> valid IP address,   but  the leading zeros make it non-compliant with
> the standard representation of an IP address;   the result is
> ill-defined, and the octal interpretation is very common.

Jimmy,

The RFC literature quite liberally refers to the notation as "dotted-decimal" and therefore zero-padding is a good faith interpretation of the standard form. That being said...

> For example,
>   "012.020.030.040"   actually  indicates the IP address "10.16.24.32"
> 
> [root at orb1 ~ ]# ping -c 5 012.020.030.040
> PING 012.020.030.040 (10.16.24.32) 56(84) bytes of data.
>                                        ^^^^^^^^^^^
> 
> 
> ^C
> cat <<END > blah.c
>> #include <stdio.h>
>> #include <arpa/inet.h>
>> 
>> int main()
>> {
>>   char* input = "012.020.030.040";    struct in_addr address;
>> 
>>   if ( inet_aton(input, &address) != -1) {
>>      printf("%s == %s == %d == %X\n", input, inet_ntoa(address), htonl(address.s_addr), >htonl(address.s_addr));
>>   }
>> }
> END
> $ ./blah
> 012.020.030.040 == 10.16.24.32 == 168826912 == A101820
> $

I can see how this would trip up C programs and any languages using the inet_aton system call directly. Thanks for the example code.

As I replied to Seth, we can add elements that do not have the zero padding if that is what you desire.

Andy Newton

From mysidia at gmail.com  Fri Mar 30 09:33:26 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Fri, 30 Mar 2012 08:33:26 -0500
Subject: [arin-tech-discuss] zero-padded IP addresses in "startAddress"
 and "endAddress" values
In-Reply-To: <B1E69E62-24FC-4F45-B3C9-48942AADF1C0@arin.net>
References: <CB98E0A0.12343%dhuberma@corp.arin.net>
	<4F7371E4.3050504@rollernet.us>
	<A236635F-0749-4DF0-928C-8B8D8C43A16E@arin.net>
	<4F751539.20809@rollernet.us>
	<B1E69E62-24FC-4F45-B3C9-48942AADF1C0@arin.net>
Message-ID: <CAAAwwbV53at5CPxM7roxDWd9zqeEEnUuFvJsFkKWb4n1Wbr2Gg@mail.gmail.com>

On Fri, Mar 30, 2012 at 7:54 AM, Andy Newton <andy at arin.net> wrote:
> On Mar 30, 2012, at 4:06 AM, Seth Mattinen wrote:

> That long-winded explanation aside, we can certainly take steps to make programming against the >Reg-RWS interface easier if the community desires. New elements can be added that do not have the >zero-padded IP addresses. I do not recommend modifying the current elements as we may break code >that counts on the zero padding. And, as David stated, we should update our documentation. Would

I would suggest versioning the API;   for example if version X is used
the format is A, if version Y of the API is used then the format is B;
and adding an optional attribute to the element to indicate the format
of its contents.


>adding new elements containing IP addresses that are not zero-padded be helpful?

--
-JH


From droisman at softlayer.com  Fri Mar 30 09:46:19 2012
From: droisman at softlayer.com (Dani Roisman)
Date: Fri, 30 Mar 2012 13:46:19 +0000
Subject: [arin-tech-discuss] zero-padded IP addresses in "startAddress"
 and "endAddress" values
In-Reply-To: <B1E69E62-24FC-4F45-B3C9-48942AADF1C0@arin.net>
References: <CB98E0A0.12343%dhuberma@corp.arin.net>
	<4F7371E4.3050504@rollernet.us>
	<A236635F-0749-4DF0-928C-8B8D8C43A16E@arin.net>
	<4F751539.20809@rollernet.us>
	<B1E69E62-24FC-4F45-B3C9-48942AADF1C0@arin.net>
Message-ID: <C40B18ECB19B374EBB7B033835339F1D6E7C3622@SM-DAG152.softlayer.local>

Andy - thanks for considering this.  David mentioned earlier in the thread that it's always been this way - is that really accurate?  I don't have historical examples, but when we first coded to the RESTful API late in 2011, we didn't see the zero-padding of IPs.

----
Dani Roisman
VP, Network Operations
droisman at softlayer.com
(281) 714-3714 direct 
(818) 481-5581 cell

| -----Original Message-----
| From: arin-tech-discuss-bounces at arin.net [mailto:arin-tech-discuss-
| bounces at arin.net] On Behalf Of Andy Newton
| Sent: Friday, March 30, 2012 07:54
| To: Seth Mattinen
| Cc: <arin-tech-discuss at arin.net>
| Subject: Re: [arin-tech-discuss] zero-padded IP addresses in "startAddress"
| and "endAddress" values
| 
| 
| On Mar 30, 2012, at 4:06 AM, Seth Mattinen wrote:
| 
| > I personally treat IP addresses as unsigned integers (or double/float
| > for IPv6). It never occurred to me to treat an IP as a string since it's
| > supposed to represent a 32-bit or 128-bit number. Integer comparisons
| > are, IMO, easier.
| 
| Seth,
| 
| Interpretation of IP addresses as numbers makes complete sense. But I will
| note that some languages do not have unsigned integers and double and
| float on many platforms, languages, and databases are only 64 bits. Float can
| be particularly troublesome as IEEE 754 interpretations of it only give 56 bits
| of precision.
| 
| Comparison as a numeric type is also natural, but in a database where an IP
| address column is indexed that difference is only important for an r-tree
| index which are not very common. Additionally in a database context,
| substring matching can be used for prefix queries, though admittedly only on
| octet boundaries.
| 
| Like you, my first inclination as a programmer is to treat IP addresses as
| numbers. And when I first encountered the usage of zero-padded IP address
| strings, doing so had never occurred to me. That being said, in my career
| ARIN is not the first place I have seen this, and in the ARIN codebases we
| have found this pattern many times, implemented by multiple coders in
| many subsystems, going back to code that well predates ARIN.
| 
| That long-winded explanation aside, we can certainly take steps to make
| programming against the Reg-RWS interface easier if the community desires.
| New elements can be added that do not have the zero-padded IP addresses.
| I do not recommend modifying the current elements as we may break code
| that counts on the zero padding. And, as David stated, we should update our
| documentation. Would adding new elements containing IP addresses that
| are not zero-padded be helpful?
| 
| Andy Newton
| _______________________________________________
| arin-tech-discuss mailing list
| arin-tech-discuss at arin.net
| http://lists.arin.net/mailman/listinfo/arin-tech-discuss


From andy at arin.net  Fri Mar 30 10:23:07 2012
From: andy at arin.net (Andy Newton)
Date: Fri, 30 Mar 2012 14:23:07 +0000
Subject: [arin-tech-discuss] zero-padded IP addresses in "startAddress"
 and "endAddress" values
In-Reply-To: <CAAAwwbV53at5CPxM7roxDWd9zqeEEnUuFvJsFkKWb4n1Wbr2Gg@mail.gmail.com>
References: <CB98E0A0.12343%dhuberma@corp.arin.net>
	<4F7371E4.3050504@rollernet.us>
	<A236635F-0749-4DF0-928C-8B8D8C43A16E@arin.net>
	<4F751539.20809@rollernet.us>
	<B1E69E62-24FC-4F45-B3C9-48942AADF1C0@arin.net>
	<CAAAwwbV53at5CPxM7roxDWd9zqeEEnUuFvJsFkKWb4n1Wbr2Gg@mail.gmail.com>
Message-ID: <108728ED-3C28-43B4-9415-94C9BBE0D765@arin.net>


On Mar 30, 2012, at 3:33 PM, Jimmy Hess wrote:

> I would suggest versioning the API;   for example if version X is used
> the format is A, if version Y of the API is used then the format is B;
> and adding an optional attribute to the element to indicate the format
> of its contents.


Thanks Jimmy. Yes we will version it. More than likely we will add additional elements using another XML namespace, that way both elements are present but distinguishable.

Again, thanks for the code sample. And I'm sorry for the inconvenience this has caused.

Note that there is an upcoming modification to the Reg-RWS interface but unfortunately it will not contain this modification as that software is already "in the can."

-andy

From andy at arin.net  Fri Mar 30 10:31:55 2012
From: andy at arin.net (Andy Newton)
Date: Fri, 30 Mar 2012 14:31:55 +0000
Subject: [arin-tech-discuss] zero-padded IP addresses in "startAddress"
 and "endAddress" values
In-Reply-To: <C40B18ECB19B374EBB7B033835339F1D6E7C3622@SM-DAG152.softlayer.local>
References: <CB98E0A0.12343%dhuberma@corp.arin.net>
	<4F7371E4.3050504@rollernet.us>
	<A236635F-0749-4DF0-928C-8B8D8C43A16E@arin.net>
	<4F751539.20809@rollernet.us>
	<B1E69E62-24FC-4F45-B3C9-48942AADF1C0@arin.net>
	<C40B18ECB19B374EBB7B033835339F1D6E7C3622@SM-DAG152.softlayer.local>
Message-ID: <47B3E184-FC8D-45AB-AB67-27DB38047999@arin.net>


On Mar 30, 2012, at 3:46 PM, Dani Roisman wrote:

> Andy - thanks for considering this.  David mentioned earlier in the thread that it's always been this way - is that really accurate?  I don't have historical examples, but when we first coded to the RESTful API late in 2011, we didn't see the zero-padding of IPs.

Dani,

To be truthful I had forgotten this difference between Whois-RWS and Reg-RWS. But to our knowledge, yes this has already been the case. We had our QA department double check it.

However, our Reg-RWS documentation says it will be returned without zero padding. So this is our mistake. Sorry for the inconvenience.

Andy Newton

From andy at arin.net  Fri Mar 30 11:59:08 2012
From: andy at arin.net (Andy Newton)
Date: Fri, 30 Mar 2012 15:59:08 +0000
Subject: [arin-tech-discuss] zero-padded IP addresses in "startAddress"
 and "endAddress" values
In-Reply-To: <108728ED-3C28-43B4-9415-94C9BBE0D765@arin.net>
References: <CB98E0A0.12343%dhuberma@corp.arin.net>
	<4F7371E4.3050504@rollernet.us>
	<A236635F-0749-4DF0-928C-8B8D8C43A16E@arin.net>
	<4F751539.20809@rollernet.us>
	<B1E69E62-24FC-4F45-B3C9-48942AADF1C0@arin.net>
	<CAAAwwbV53at5CPxM7roxDWd9zqeEEnUuFvJsFkKWb4n1Wbr2Gg@mail.gmail.com>
	<108728ED-3C28-43B4-9415-94C9BBE0D765@arin.net>
Message-ID: <36F86BB6-0F6D-4717-8ED2-E03F37E01974@arin.net>

All,

So that we may track this suggested improvement and have it considered for prioritization with other software improvements and changes, will one of you in the community please file this in the ACSP system. That form can be found here:

https://www.arin.net/app/suggestion/

A reference to this thread describing this issue is here: http://lists.arin.net/pipermail/arin-tech-discuss/2012-March/000192.html

Thanks in advance.

Andy Newton,
Chief Engineer, ARIN

From karl.baum at gmail.com  Fri Mar 30 17:44:34 2012
From: karl.baum at gmail.com (Karl Baum)
Date: Fri, 30 Mar 2012 17:44:34 -0400
Subject: [arin-tech-discuss] mapping ip addresses to domains
In-Reply-To: <B9EBD2474913AD4A995B8C7B8BEF8C0E150E6D57E0@FHDP1LUMXC7V43.us.one.verizon.com>
References: <5A8EE213-C531-4648-9214-D9FAE458D954@gmail.com>
	<CB9A483F.123A1%dhuberma@corp.arin.net>
	<B9EBD2474913AD4A995B8C7B8BEF8C0E150E6D57E0@FHDP1LUMXC7V43.us.one.verizon.com>
Message-ID: <40577074-975D-490E-9E12-317DE827A778@gmail.com>

For my purposes i am trying to match ip addresses to companies.  Looking at the data thus far, it seems pretty rare that the poc domains do not match a company domain.  It's not horrible for me if using domain of pocs is not 100% accurate as i am only enriching the data output of a report.

Thanks for your help!

-karl


On Mar 30, 2012, at 11:00 AM, Schiller, Heather A wrote:

> 
> If it's the domains you are after, don't make the broad assumption that they match cleanly or mean anything in relation to the IP.  There is no requirement that the domain used in the email address on a poc record, be unique to that assignment/company or belong to them.  For example, if a poc record has @gmail.com that doesn't mean the IP's have anything to do with Google.  I can't imagine that the domain portion of an email address generates anything reliably useful for any purpose.
> 
> --Heather
> 
> -----Original Message-----
> From: arin-tech-discuss-bounces at arin.net [mailto:arin-tech-discuss-bounces at arin.net] On Behalf Of David Huberman
> Sent: Thursday, March 29, 2012 5:15 PM
> To: Karl Baum; arin-tech-discuss at arin.net
> Subject: Re: [arin-tech-discuss] mapping ip addresses to domains
> 
> Hiya Karl,
> 
> Service providers have the option of registering reassignments either with or without customer POC information.  In the cases when they choose not to publish customer POC information (and thus the network is associated with a customer ID rather than an Org ID), there's not enough data provided to connect an IP address range with a possibly-associated domain.
> 
> Regards,
> David
> 
> ---
> David R Huberman
> Principal Technical Analyst, ARIN
> 703-227-9866
> 
> 
> 
> 
> 
> 
> 
> On 3/29/12 4:21 PM, "Karl Baum" <karl.baum at gmail.com> wrote:
> 
> If i have an ip address, many times i can map that ip to email domains by jumping from ip to org to pocs.  The problem i run into is that many times the ip is not associated with an org but instead a customer.  For example:
> 
> https://gist.github.com/9429c3683719eff115fb
> 
> Is there a way to get to the pocs in this case?
> 
> thx!
> 
> -karl
> _______________________________________________
> arin-tech-discuss mailing list
> arin-tech-discuss at arin.net
> http://lists.arin.net/mailman/listinfo/arin-tech-discuss
> 
> _______________________________________________
> arin-tech-discuss mailing list
> arin-tech-discuss at arin.net
> http://lists.arin.net/mailman/listinfo/arin-tech-discuss