Do they have the requisite staff and funding?
I truly want to believe that, and I do appreciate the effort that Willam
and Elan put into this. That said, I do near-daily diffs between
changes made to
http://completewhois.com/bogons/data/data-bgp-announced/announced_bogon-cidr-all.txt
Here are today's deletions from Friday's list, do bogons really change
that frequently?
76.0.0.0/13
76.0.0.0/19
133.1.0.0/16
133.2.0.0/16
133.3.0.0/16
133.4.0.0/16
133.5.0.0/16
133.6.0.0/16
133.7.0.0/16
133.8.0.0/16
133.9.0.0/16
133.10.0.0/16
133.11.0.0/16
133.12.0.0/16
133.13.0.0/16
133.13.0.0/17
133.14.0.0/16
133.15.0.0/16
133.16.0.0/16
133.17.0.0/16
133.18.0.0/16
133.19.0.0/16
133.20.0.0/16
133.21.0.0/16
133.23.0.0/16
133.24.0.0/16
133.25.0.0/16
133.26.0.0/16
133.27.0.0/16
133.28.0.0/16
133.29.0.0/16
133.30.0.0/16
133.31.0.0/16
133.33.0.0/16
133.34.0.0/16
133.35.0.0/16
133.36.0.0/16
133.37.0.0/16
133.38.0.0/16
133.39.0.0/16
133.40.0.0/16
133.41.0.0/16
133.42.0.0/16
133.43.0.0/16
133.44.0.0/16
133.45.0.0/16
133.46.0.0/16
133.47.0.0/16
133.48.0.0/16
133.49.0.0/16
133.50.0.0/16
133.51.0.0/16
133.52.0.0/16
133.52.0.0/17
133.53.0.0/16
133.54.0.0/16
133.55.0.0/16
133.56.0.0/16
133.57.0.0/16
133.58.0.0/16
133.60.0.0/16
133.62.0.0/16
133.63.0.0/16
133.64.0.0/16
133.65.0.0/16
133.66.0.0/16
133.67.0.0/16
133.68.0.0/16
133.69.0.0/16
133.70.0.0/16
133.71.0.0/16
133.72.0.0/16
133.73.0.0/16
133.74.0.0/16
133.75.0.0/16
133.77.0.0/16
133.78.0.0/16
133.79.0.0/16
133.80.0.0/16
133.82.0.0/16
133.83.0.0/16
133.85.0.0/16
133.86.0.0/16
133.87.0.0/16
133.88.0.0/16
133.89.0.0/16
133.91.0.0/16
133.92.0.0/16
133.94.0.0/16
133.95.0.0/16
133.96.0.0/16
133.97.0.0/16
133.98.0.0/16
133.99.0.0/16
133.100.0.0/16
133.101.0.0/16
133.102.0.0/16
133.103.0.0/16
133.104.0.0/16
133.105.0.0/16
133.106.0.0/16
133.109.0.0/16
133.111.0.0/16
133.121.0.0/16
133.125.0.0/17
133.127.0.0/16
133.130.0.0/16
133.137.0.0/16
133.138.0.0/16
133.140.0.0/16
133.145.0.0/16
133.146.0.0/16
133.148.0.0/16
133.149.0.0/16
133.152.0.0/16
133.153.0.0/16
133.158.0.0/16
133.163.0.0/16
133.164.0.0/16
133.169.0.0/16
133.170.0.0/16
133.173.0.0/16
133.176.0.0/16
133.186.0.0/16
133.187.0.0/16
133.188.0.0/16
133.192.0.0/16
133.194.0.0/16
133.205.0.0/16
133.215.0.0/16
133.216.0.0/16
133.217.0.0/16
133.218.0.0/16
133.220.0.0/16
133.221.0.0/16
133.225.0.0/16
133.226.0.0/16
133.232.0.0/16
133.235.0.0/16
133.236.0.0/16
133.237.0.0/16
133.238.0.0/16
133.240.0.0/16
133.243.0.0/16
133.245.0.0/16
133.249.0.0/16
133.250.0.0/16
133.253.0.0/16
133.254.0.0/16
193.33.178.0/23
I'm just trying to get a complete (not constantly changing) list of
bogons.
-Jim P.
> 10/8 used to be a DoD address block, but it was also used
exclusively in
> their blacker networks and similar non-connected infrastructure. The
> result is that 10/8 was opened up for others to use as
well. Could we do
> similar with 7/8?What problem would that solve instead of reducing a wee tiny bit the
collisions that might occur? Large networks are currently already
established and renumbering them from 10.0.0.0/8 to 7.0.0.0/8 would
still be renumbering.
Renumbering? Was somebody discussing renumbering?
The problem that releasing 7/8 would solve is that IANA could allocate
it to an RIR and the RIR could allocate it to customers. Given the
finite nature of the IPv4 space, it is a bad thing to lock away address
blocks that could be used by others.
Also note that Fastweb in Italy is already using 7.0.0.0/8
inside their
network for their customers, who sit behind a NAT.
And I know a company that has been using 1/8, 2/8, 3/8, 4/8, 5/8, 6/8,
7/8 and 8/8 for many years, also behind NAT or on non-Internet connected
networks. But that is not what I am talking about here.
In fact, I would like to see a mechanism where large address blocks used
primarily in a single geographic area, are made available for reuse in
other geographic areas. This would extend the lifetime of IPv4.
--Michael Dillon
Eventually all the reserved for future allocation blocks will be allocated for use, and will no longer be "bogons."
That is independent of which blocks are routed or routable on the Internet.
Once upon a time, the NIC (i.e. SRI-NIC) had a field for "connected status" in their database of addresses. There are several network
blocks allocated, but not "connected" to the Internet.
Perhaps IANA and the RIRs can bring "connected status" back?
> As a result, most people consider William Leibzon and the Bogon project
> to be, collectively, the authoritative source for information on whose
> IP address that is. That's because William and the Bogon project, act
> authoritative, and take some pains to provide comprehensive data.I truly want to believe that, and I do appreciate the effort that Willam
and Elan put into this. That said, I do near-daily diffs between
changes made to
http://completewhois.com/bogons/data/data-bgp-announced/announced_bogon-cidr-all.txtHere are today's deletions from Friday's list, do bogons really change
that frequently?
133.1.0.0/16
...
133.254.0.0/16
193.33.178.0/23
NetRange: 133.0.0.0 - 133.255.255.255
CIDR: 133.0.0.0/8
NetName: JAPAN-INET
NetHandle: NET-133-0-0-0-1
Parent:
NetType: Direct Allocation
inetnum: 193.33.178.0 - 193.33.179.255
netname: NOWIRES-PI
descr: No Wires Ltd
country: GB
org: ORG-NWL1-RIPE
admin-c: AT4098-RIPE
tech-c: JC2953-RIPE
status: ASSIGNED PI
neither of those seem to be bogons... but I could be wrong in some way,
I'm sure.
Er, no, it was the ARPANET's block. (See the Assigned Numbers RFCs up to
990.)
Tony.
As a result, most people consider William Leibzon and the Bogon project
to be, collectively, the authoritative source for information on whose
IP address that is.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
If that's the case, all hope has been lost.
That's because William and the Bogon project, act authoritative, and
take some pains to provide comprehensive data. At the same time, IANA
and the RIRs just keep doing the same old thing as their data and
systems slowly rot away.
Why doesn't IANA operate a whois server?
Why should they? What will it produce?
Why don't they publish a more detailled explanation field in each IANA
allocation record so that they can explain the precise status of each
block?
Why should they?
Why doesn't IANA and the RIRs collectively get off their butts and
actually make an "authoritative IP address allocation directory" one of
their goals?And why don't they do all this with some 21st century technology?
Why doesn't vwl help by giving ARIN his changelog, if any?
-alex
>> We checked with IANA, ARIN, and the US DoD regarding 7.0.0.0/8. We
>> were told that this netblock should not see the light of day,
>
> 10/8 used to be a DoD address block, but it was also used exclusively in
> their blacker networks and similar non-connected infrastructure. The
> result is that 10/8 was opened up for others to use as well. Could we do
> similar with 7/8?What problem would that solve instead of reducing a wee tiny bit the
collisions that might occur? Large networks are currently already
established and renumbering them from 10.0.0.0/8 to 7.0.0.0/8 would
still be renumbering. For those networks it is much better to simply get
a block from their RIR and use that and never have collisions.
Set up a private allocation registry, and allocate chunks of 7/8 (or some other block that is generally available) to companies for a small annual fee. This would open up space for use in private networks that would then be sufficiently unique to cross-connect, merge or at least provide a bit of landing space for use as border addressing in organizations that are hopelessly over-using 10/8, 192.168/16 and 172.16/12 and need some space that's guaranteed unique for dealing with intercompany private interconnects, mergers or whatever.
I recall discussion of approaches with IPv6 to do something more intelligent in doling out private address space in ways that'd help limit conflicts. Why not make use of more DoD space to do something like this in IPv4?
Also note that Fastweb in Italy is already using 7.0.0.0/8 inside their
network for their customers, who sit behind a NAT.
Oh well, so much for using that block for a registry driven allocation system then. Any other blocks that could be used?
As a result, most people consider William Leibzon and the Bogon project
to be, collectively, the authoritative source for information on whose
IP address that is. That's because William and the Bogon project, act
authoritative, and take some pains to provide comprehensive data.
Its not authoritative. IANA and ARIN should be authoritative unless
there are issues with their data as I for example raised. My project
should be considered research with a lot of practical use (but which
also with errors and bugs as with other research projects).
I truly want to believe that, and I do appreciate the effort that Willam
and Elan put into this. That said, I do near-daily diffs between
changes made to
http://completewhois.com/bogons/data/data-bgp-announced/announced_bogon-cidr-all.txtHere are today's deletions from Friday's list, do bogons really change
that frequently?76.0.0.0/13
76.0.0.0/19
Its same glitch I mentioned before, which is not entirely fixed yet.
The data before was:
76.0.0.8/29
76.0.0.16/28
76.0.0.32/27
...
76.0.128.0/17
76.1.0.0/16
76.2.0.0/15
76.4.0.0/14
The correct entry is obviously 76.0.0.0/13
133/8 is special case because APNIC does not import this data in their whois.
Completewhois collection system does separate whois query to nic.ad.jp for each individual /16 out of it to find which of the blocks are and are not allocated. There are issues when data is not received properly or when they change format; plus to that there is no 2nd way to correlate the data as for example between RIR whois and statistics data. JPNIC also at times does not respond so as a result of all this, I changed collection to run not once a day but once/week (this was done over year ago) and at times check data manually too. Last time this collection was run was run is Apr 15th 4am which produced the following _correct_ list of bogons for 133/8
(this special data is at http://www.completewhois.com/bogons/data/jp/):
133.0.0.0/16
133.22.0.0/16
133.59.0.0/16
133.61.0.0/16
133.81.0.0/16
133.90.0.0/16
133.93.0.0/16
133.107.0.0/16
133.112.0.0/16
133.124.0.0/16
133.143.0.0/16
133.147.0.0/16
133.156.0.0/16
133.171.0.0/16
133.174.0.0/16
133.177.0.0/16
133.178.0.0/15
133.195.0.0/16
133.212.0.0/16
133.230.0.0/15
133.234.0.0/16
133.239.0.0/16
133.246.0.0/16
However previous days the data looked like this:
133.0.0.0/16
133.1.0.0/30
133.2.0.0/30
133.3.0.0/30
...
So in fact it was improperly listing first 4 ips of the each /16
(but not entire /16 as you printed). In actuallity its also exactly
the same bug just manifesting itself in different way due to how JPNIC collection is done.
193.33.178.0/23
inetnum: 193.33.178.0 - 193.33.179.255
netname: NOWIRES-PI
descr: No Wires Ltd
country: GB
org: ORG-NWL1-RIPE
admin-c: AT4098-RIPE
tech-c: JC2953-RIPE
status: ASSIGNED PI
mnt-by: RIPE-NCC-HM-PI-MNT
mnt-by: CRYSTAL-MNT
mnt-lower: RIPE-NCC-HM-PI-MNT
mnt-routes: CRYSTAL-MNT
mnt-domains: CRYSTAL-MNT
changed: hostmaster@ripe.net 20070413
source: RIPE
Unless I'm mistaken this is new PI allocation done 2 days ago. So
system worked as it should be removing it from the bogons list.
I'm just trying to get a complete (not constantly changing) list of
bogons.
The list changes and collection are done everyday on purpose as completewhois system produced data not on IANA bogons which change infrequently but more specific bogon data based on RIR allocations,
i.e. it tries to catch and list portions of blocks that IANA allocated
to RIR but RIR has not yet allocated/assigned to end-user or ISP.
As RIRs make allocations basicly every business day, completewhois
data is recollected to make sure it corresponds to most current data.
Why doesn't IANA operate a whois server?
In fact they do operate whois server at whois.iana.org.
However that has domain data for .arpa and .int and not IPv4 whois
data which IANA has historically provided using flat file pointer
while having RIR maintain specific whois data even for /8 directly
listed in IANA file. Exactly because they do not operate ip whois
in the flat file "based" on IANA data that for me serves as "root":
http://www.completewhois.com/iana-ipv4-addresses.txt
for each IANA allocated block the listed whois server is whois.arin.net
Why don't they publish a more detailled explanation field in each IANA
allocation record so that they can explain the precise status of each
block?
This question as well as suggestion for IANA to operate "root" ip
whois server for /8 bloks should probably be sent to iana@iana.org.
(but its also possible that IANA people reading this list will respond...)
Why doesn't IANA and the RIRs collectively get off their butts and
actually make an "authoritative IP address allocation directory" one of
their goals?
And why don't they do all this with some 21st century technology?
A new system based on IRIS protocol (XML based using BEEP as transport) will be in place in the future that will work better as a comprehensive directory.
> Why doesn't IANA operate a whois server?
Why should they? What will it produce?
It will produce an authoritative source of information that automated
systems can query and where those systems can reliably parse the output.
In cases where a human needs to check unusual cases, there will be a
complete explanation in the comments field of the whois output.
> Why don't they publish a more detailled explanation field
in each IANA
> allocation record so that they can explain the precise
status of each
> block?
Why should they?
In order to be authoritative one must be seen to be authoritative. When
the information is not available, people are more likely to attribute
this to incompetence than secrecy.
> And why don't they do all this with some 21st century technology?
Why doesn't vwl help by giving ARIN his changelog, if any?
Who is vwl and why should this mysterious person give their changelog to
ARIN. Assuming that this represents changes to something, what is that
something.
--Michael Dillon
> Why doesn't IANA and the RIRs collectively get off their butts and
> actually make an "authoritative IP address allocation
directory" one of
> their goals?
> And why don't they do all this with some 21st century technology?A new system based on IRIS protocol (XML based using BEEP as
transport)
will be in place in the future that will work better as a
comprehensive
directory.
I have heard of no such plans. As far as I know, IRIS was designed for
domain name registry whois data which is entirely a separate issue from
IP address whois data. Also, I do not consider a complex XML-based
protocol to be 21st century technology. In the 20th century, when you
wanted to do something on the net you invented a new protocol and hacked
together some application.
In the 21st century, you look at what is available on the shelf and
widely in use on the net and adopt that. Most often this turns out to be
a RESTful API that doesn't even need XML, although something like
XML-RPC still fits the bill. I still wonder why the widely used LDAP
protocol can't be adopted for whois lookups since it is used everywhere
in the corporate world. The answer seems to be Not-Invented-Here or
"we're netheads and LDAP smells of bellheads", both of which are
ridiculous arguments in the today's world.
--Michael Dillon
Come on, let's not get carried away.
The problem with the IANA file is that "reserved" is ambiguous and there are other things in there that get in the way of easy parsing. This is easy enough to fix. Geoff Huston wrote a draft suggesting how to do it.
Whois, LDAP and other stuff like that only makes things worse because this requires you to walk through the data rather than have it available in a nice, easy to handle text file.
Come on, let's not get carried away.
The problem with the IANA file is that "reserved" is ambiguous and
there are other things in there that get in the way of easy parsing.
This is easy enough to fix. Geoff Huston wrote a draft
suggesting how
to do it.Whois, LDAP and other stuff like that only makes things worse
because
this requires you to walk through the data rather than have it
available in a nice, easy to handle text file.
Yes, let's not get carried away. The data is already available in a
nice, easy to handle text file for those that simply want to look at a
simple listing. But for those who NEED to parse it with automated
systems and who NEED to know when things have changed, an IANA whois
server is a better solution. Whois has things like Regdate, Updated, and
a Comment field which just don't fit in a simple text file.
And let's also not get carried away with writing Internet drafts to tell
IANA how to fix a problem that they really should be INDEPENDENTLY
fixing because it is the right thing to do. I would like to see IANA
respond to complaints, but I would not like to see IANA sit on their
hands and wait until the IETF discusses and passes an RFC to define what
IANA should be doing.
Also, my comments about RESTful API, XML-RPC and LDAP were directed at
ARIN, not at IANA.
--Michael Dillon
But for those who NEED to parse it with automated
systems and who NEED to know when things have changed, an IANA whois
server is a better solution. Whois has things like Regdate, Updated, and
a Comment field which just don't fit in a simple text file.
Just to note, I believe that Leo Vegoda touched on IANA developing a whois service for IP Addressing at the last UKNOF meeting in Manchester; however I may have been mistaken/ misunderstood.
http://www.uknof.org.uk/uknof7/Vegoda-IANA.pdf
From his talk however, I do believe they are trying to make their interaction with the community better and also provide the
services that we ask of them.
S
This message has been scanned for viruses by MailController - www.MailController.altohiway.com
No, it's not. My scripts currently retrieve the file, compare what's in there with what's in the database and complain when there is a difference. All simple enough. The only problem is that I need a bunch of special case logic and have to check up manually to make sure that everything is categorized correctly.
With whois, I'd need to do 256 lookups, and I'd probably have to implement the whois protocol myself (ok, trivial, but still) because I can't just use one of the 3 million HTTP utils/libraries.
[...]
Just to note, I believe that Leo Vegoda touched on IANA developing a whois service for IP Addressing at the last UKNOF meeting in Manchester; however I may have been mistaken/ misunderstood.
Yes, we're working hard on making our registry data as easy to access as possible. We're also working with the RIRs to update the data IPv4 registry. We have made a few updates over the last few months and are working on others.
Regards,
With whois, I'd need to do 256 lookups, and I'd probably have to
implement the whois protocol myself (ok, trivial, but still) because
I can't just use one of the 3 million HTTP utils/libraries.
Really?
Do you know for a fact that the IANA whois server will not support
lookups for 0.0.0.0 and return a complete set of entries in one query?
Your comment about the whois protocol is one of the funniest things I've
heard all year. Whois is about as complex as the TCP echo protocol found
on port 7. Here is an example in Python:
import socket
server = "whois.arin.net"
whoisport = 43
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((server, whoisport))
s.send("+ 199.1.2.3\n")
print s.recv(8192)
Nevertheless, I agree about using HTTP. The following basically works:
import urllib
answer =
urllib.urlopen("http://ws.arin.net/whois?queryinput=199.4.5.6").read()
print answer
However, to parse it you have to go to the second PRE block to extract
the data. If ARIN would supply a whois service that was designed to be
used with a RESTful API, then it could leave off all the HTML crud that
is there for an interactive viewer and maybe provide the data in XML or
JSON format rather than the RFC 2822/2068 header format.
--Michael Dillon
Why doesn't IANA and the RIRs collectively get off their butts and
actually make an "authoritative IP address allocationdirectory" one of
their goals?
And why don't they do all this with some 21st century technology?A new system based on IRIS protocol (XML based using BEEP as
transport)
will be in place in the future that will work better as a
comprehensive
directory.I have heard of no such plans. As far as I know, IRIS was designed for
domain name registry whois data which is entirely a separate issue from
IP address whois data.
http://www.ietf.org/html.charters/crisp-charter.html
http://www.ietf.org/rfc/rfc4698.txt
Also, I do not consider a complex XML-based
protocol to be 21st century technology. In the 20th century, when you
wanted to do something on the net you invented a new protocol and hacked
together some application.
You need more then just transport to make an application protocol. Whois really does not have standardized format or querying mechanisms or security
mechanisms and that is why all this work. Underlying transport is less of
an issue and I personally was actually for LDAP when group was making a
choice between LDAP-based and XML/BEEP-based foundation.
Michael,
The world moved on around them but you
still see things like IANA's non-parseable text file
The text file is parseable -- we have empirical evidence. Every time we change the format slightly, people yell at us.
At the
same time, IANA and the RIRs just keep doing the same old thing as their
data and systems slowly rot away.
Not really. I can't speak to the RIRs, but IANA is working on both cleaning up the data in all our registries as well as coming up with an XML-based alternative representation for those registries.
Why doesn't IANA operate a whois server?
We do. The proper question to ask is why isn't our whois server populated with address information instead of just domain name information. I don't know the reason historically. However, today, when the topic was recently raised, concerns were expressed that IANA would be seen in competition with the RIRs and there are those that believe IANA (ICANN) should have no "operational" role whatsoever. With that said, IANA continues to look at adding top level (i.e., /8s for IPv4) block allocation information to the IANA whois server and this is something we're discussing with the RIRs -- I don't think anybody is particularly happy with the current state of affairs.
Why don't they publish a more detailled explanation field in each IANA
allocation record so that they can explain the precise status of each
block?
What sort of additional information would be helpful? As mentioned above, we're preparing an XML-based alternative representation of various IANA registries which would give us a lot more flexibility than the current text based representation. Feel free to send mail privately as this might get a bit down in the weeds for NANOG.
Why doesn't IANA and the RIRs collectively get off their butts and
actually make an "authoritative IP address allocation directory" one of
their goals?
Improving the IANA registries is one of our goals. While I can't speak to the RIRs, I suspect it is one of their goals as well.
And why don't they do all this with some 21st century technology?
I was wondering when LDAP would show up in this discussion... 
Rgds,
-drc