Question on 7.0.0.0/8
Anybody know if 7.0.0.0/8 is or is not allocated to DoD? The data at IANA and ARIN is kind-of confusing... --------------------------------------------------------------- 7.1.1.0/24 ## AS1239 : SPRINTLINK : Sprint 7.0.0.0 - 7.255.255.255 ## Bogon (unallocated) ip range --------------------------------------------------------------- http://www.iana.org/assignments/ipv4-address-space 007/8 Apr 95 IANA - Reserved --------------------------------------------------------------- [IPv4 whois information for 7.0.0.1 ] [whois.arin.net] OrgName: DoD Network Information Center OrgID: DNIC Address: 3990 E. Broad Street City: Columbus StateProv: OH PostalCode: 43218 Country: US NetRange: 7.0.0.0 - 7.255.255.255 CIDR: 7.0.0.0/8 NetName: DISANET7 NetHandle: NET-7-0-0-0-1 Parent: NetType: Direct Allocation Comment: RegDate: 1997-11-24 Updated: 2006-04-28 OrgTechHandle: MIL-HSTMST-ARIN OrgTechName: Network DoD OrgTechPhone: +1-800-365-3642 OrgTechEmail: HOSTMASTER@nic.mil -- William Leibzon Elan Networks william@elan.net
CYMRU has 7/8 listed as a bogon: http://www.cymru.com/Documents/bogon-dd.html Their list is more or less authoritative, so I would believe that you should never see traffic from that netblock. This is also consistent with Sprint blackholeing it as a bogon in your original post. That said, it doesn't mean that the netblock is unused. Most likely it is a netblock that DoD actually uses, but it is only routed on DoD's private backbone and never on the Internet. If you are seeing traffic to/from that netblock, there are two possibilities that come to mind: 1) Spoofed source IPs on UDP and ICMP traffic. 2) If it is TCP traffic, then probably someone has hijacked the netblock and is publishing BGP routes to it. Hijacking unallocated netblocks has been a common spamming technique for at least 10 years -- although with today's botnets it does not appear to be as commonly used (IMHO). Also, the spammers usually try to hide within smaller unallocated netblocks (< /16) of allocated netblocks (a little less obvious and less likely to be blackholed). If you are seeing traffic to/from this netblock, PLEASE do a traceroute back to that IP -- in fact do several from different networks -- to make it easier for law enforcement to trace back to the hijacker. Also, try using something more smarter than standard traceoute, such as: http://www.paris-traceroute.net/ If you are seeing traffic from hijacked netblocks, contact your local InfraGuard group -- I know the FBI will be VERY interested in that information. Jon Kibler william(at)elan.net wrote:
Anybody know if 7.0.0.0/8 is or is not allocated to DoD? The data at IANA and ARIN is kind-of confusing...
--------------------------------------------------------------- 7.1.1.0/24 ## AS1239 : SPRINTLINK : Sprint 7.0.0.0 - 7.255.255.255 ## Bogon (unallocated) ip range --------------------------------------------------------------- http://www.iana.org/assignments/ipv4-address-space 007/8 Apr 95 IANA - Reserved --------------------------------------------------------------- [IPv4 whois information for 7.0.0.1 ] [whois.arin.net]
OrgName: DoD Network Information Center OrgID: DNIC Address: 3990 E. Broad Street City: Columbus StateProv: OH PostalCode: 43218 Country: US
NetRange: 7.0.0.0 - 7.255.255.255 CIDR: 7.0.0.0/8 NetName: DISANET7 NetHandle: NET-7-0-0-0-1 Parent: NetType: Direct Allocation Comment: RegDate: 1997-11-24 Updated: 2006-04-28
OrgTechHandle: MIL-HSTMST-ARIN OrgTechName: Network DoD OrgTechPhone: +1-800-365-3642 OrgTechEmail: HOSTMASTER@nic.mil
-- Jon R. Kibler Chief Technical Officer Advanced Systems Engineering Technology, Inc. Charleston, SC USA (843) 849-8214
On Sat, 14 Apr 2007, Jon R. Kibler wrote:
CYMRU has 7/8 listed as a bogon: http://www.cymru.com/Documents/bogon-dd.html
Their list is more or less authoritative, so I would believe that you should never see traffic from that netblock. This is also consistent with Sprint blackholeing it as a bogon in your original post.
Their list is no more "authoritative" then mine and I suspect they simply did not look into this netblock case before. Another bogon tracking system http://www.cidr-report.org/#Bogons does not list it as bogon even though it does see same 7.1.1.0/24 announcement by Sprint. I'm also curious to know why you think that Sprintlink is blackholing it? ----- In case you're wondering they do route this block, here is where my traceroute ends: ... 11 sl-bb20-rly-12-0.sprintlink.net (144.232.7.249) 79.181 ms 76.106 ms 77.925 ms 12 sl-bb20-tuk-11-0.sprintlink.net (144.232.20.137) 97.675 ms 97.748 ms 98.021 ms 13 sl-bb21-tuk-15-0.sprintlink.net (144.232.20.133) 97.672 ms 97.579 ms 280.387 ms 14 sl-bb21-lon-14-0.sprintlink.net (144.232.19.70) 168.667 ms 169.151 ms 179.363 ms 15 sl-bb23-lon-14-0.sprintlink.net (213.206.128.54) 168.879 ms 168.922 ms 168.716 ms 16 sl-bb21-ams-3-0.sprintlink.net (213.206.129.142) 161.711 ms 161.816 ms 180.609 ms 17 sl-bb20-ham-14-0.sprintlink.net (213.206.129.50) 167.782 ms 167.884 ms 167.716 ms 18 sl-gw2-ham-0-0-0.sprintlink.net (217.147.96.100) 167.770 ms 167.928 ms 168.193 ms 19 * * * Last hop is in Germany which is a bit suspicious for supposed US DoD block but there are some military bases there after all... Also there are some interesting messages about this netblock that one can find on the net, like say: http://www.monkey.org/openbsd/archive/misc/0207/msg01215.html http://irisheagle.blogspot.com/2006_03_01_irisheagle_archive.html
That said, it doesn't mean that the netblock is unused. Most likely it is a netblock that DoD actually uses, but it is only routed on DoD's private backbone and never on the Internet.
If that is the case and they started using it in the days of J Postel with his permission, then its not a bogon. Conflicting information at ARIN and especially that their info was updated in 2006 leads me to believe that's the case. Add to it that I have several copies of old DoD hosts table and they all list it as "EDN-TEMP", but what it refers to and if the block should or should not still be in use I don't know. Unfortunately all of this does not mean you should allow (or deny) traffic from 7.0.0.0/8, but it also does not mean that if you do see any traffic that its necessarily unauthorized.
william(at)elan.net wrote:
Anybody know if 7.0.0.0/8 is or is not allocated to DoD? The data at IANA and ARIN is kind-of confusing...
--------------------------------------------------------------- 7.1.1.0/24 ## AS1239 : SPRINTLINK : Sprint 7.0.0.0 - 7.255.255.255 ## Bogon (unallocated) ip range --------------------------------------------------------------- http://www.iana.org/assignments/ipv4-address-space 007/8 Apr 95 IANA - Reserved --------------------------------------------------------------- [IPv4 whois information for 7.0.0.1 ] [whois.arin.net]
OrgName: DoD Network Information Center OrgID: DNIC Address: 3990 E. Broad Street City: Columbus StateProv: OH PostalCode: 43218 Country: US
NetRange: 7.0.0.0 - 7.255.255.255 CIDR: 7.0.0.0/8 NetName: DISANET7 NetHandle: NET-7-0-0-0-1 Parent: NetType: Direct Allocation Comment: RegDate: 1997-11-24 Updated: 2006-04-28
OrgTechHandle: MIL-HSTMST-ARIN OrgTechName: Network DoD OrgTechPhone: +1-800-365-3642 OrgTechEmail: HOSTMASTER@nic.mil
On Sat, Apr 14, 2007, william(at)elan.net wrote:
If that is the case and they started using it in the days of J Postel with his permission, then its not a bogon. Conflicting information at ARIN and especially that their info was updated in 2006 leads me to believe that's the case. Add to it that I have several copies of old DoD hosts table and they all list it as "EDN-TEMP", but what it refers to and if the block should or should not still be in use I don't know.
Unfortunately all of this does not mean you should allow (or deny) traffic from 7.0.0.0/8, but it also does not mean that if you do see any traffic that its necessarily unauthorized.
.. you can always check the RIPE BGP announcement history to see whether its been announced forever or is a recent addition, no? Are they still running that project? Adrian
On 14-apr-2007, at 11:56, william(at)elan.net wrote:
CYMRU has 7/8 listed as a bogon: http://www.cymru.com/Documents/bogon-dd.html
Their list is more or less authoritative, so I would believe that you should never see traffic from that netblock. This is also consistent with Sprint blackholeing it as a bogon in your original post.
Their list is no more "authoritative" then mine and I suspect they simply did not look into this netblock case before.
I would think IANA is authoritative... (Note that the ARIN whois server will not complain about searches for a prefix, but it won't match anything, you need to search on an IP address.) Another interesting case: 025/8 Jan 95 UK Ministry of Defense (Updated - Jan 06) # whois -h whois.arin.net 25.0.0.0 | more OrgName: DINSA, Ministry of Defence OrgID: DMD-16 Address: DINSA, HQ DCSA Address: H4, Copenacre City: Corsham StateProv: Wiltshire PostalCode: SN13 9NR Country: GB NetRange: 25.0.0.0 - 25.255.255.255 CIDR: 25.0.0.0/8 NetName: RSRE-EXP NetHandle: NET-25-0-0-0-1 Parent: NetType: Direct Assignment NameServer: NS1.CS.UCL.AC.UK NameServer: RELAY.MOD.UK Comment: RegDate: 1985-01-28 Updated: 2005-09-06 # whois -h whois.ripe.net 25.0.0.0 | more inetnum: 25.0.0.0 - 25.255.255.255 netname: UK-MOD-19850128 descr: UK Ministry of Defence country: GB org: ORG-DMoD1-RIPE admin-c: MOD123-RIPE tech-c: MOD123-RIPE status: ALLOCATED PA mnt-by: RIPE-NCC-HM-MNT I tried emailing RIPE and ARIN. hostmaster@ripe.net returned my message unread and I have no idea what other email adddress to use, hostmaster@arin.net talked at length about cleaning up the legacy A space without actually addressing the issue. Good times.
On 4/14/07, Iljitsch van Beijnum <iljitsch@muada.com> wrote: Another interesting case:
025/8 Jan 95 UK Ministry of Defense (Updated - Jan 06)
# whois -h whois.arin.net 25.0.0.0 | more OrgName: DINSA, Ministry of Defence OrgID: DMD-16 Address: DINSA, HQ DCSA Address: H4, Copenacre City: Corsham StateProv: Wiltshire PostalCode: SN13 9NR Country: GB
Fair enough. RAF Corsham is the HQ of DINSA and a few other military comms and IT orgs. NetRange: 25.0.0.0 - 25.255.255.255
CIDR: 25.0.0.0/8 NetName: RSRE-EXP NetHandle: NET-25-0-0-0-1 Parent: NetType: Direct Assignment NameServer: NS1.CS.UCL.AC.UK NameServer: RELAY.MOD.UK Comment: RegDate: 1985-01-28 Updated: 2005-09-06
Ah. I think you'll find this is a result of there being some legacy stuff from before the UK NIC, Nominet, was set up in 1996. Before then, the de facto authority was the academics, JANET, working out of the University of London Computer Centre. Hence cs.ucl.ac.uk getting in there. There are a few domain names in a similar position - post nominet, the .uk zone was reorganised to assign 2LDs like *.gov.uk, but there were already a few 1LD .uk assignments, notably mod.uk and parliament.uk. I'm not sure if it's been cleared up who is responsible for them.
On 14-apr-2007, at 12:16, Alexander Harrowell wrote: [net 25/8]
Ah. I think you'll find this is a result of there being some legacy stuff from before the UK NIC, Nominet, was set up in 1996. Before then, the de facto authority was the academics, JANET, working out of the University of London Computer Centre. Hence cs.ucl.ac.uk getting in there.
Ok, I wasn't clear: the problem here is that both ARIN and RIPE claim net 25.0.0.0/8 as "their own". This means that if you add up the address space managed by all the RIRs, net 25 gets counted twice. This is from the delegation information on their FTP servers: # grep "|25\.0\.0\.0" delegated-* delegated-arin-latest:arin|GB|ipv4|25.0.0.0|16777216|19850128|assigned delegated-ripencc-latest:ripencc|GB|ipv4|25.0.0.0|16777216|19950101| allocated Is it just me or does all of this have the odor of amateur hour around it? Inconsistencies between the various databases, IANA can't make http://www.iana.org/assignments/ipv4-address-space such that it's unambiguously parsable, ARIN backdates some of the address space it gives out, RIPE used to register address space under "UK" while that's not a valid country code (they fixed that last year, though), and so on.
* Iljitsch van Beijnum:
Ok, I wasn't clear: the problem here is that both ARIN and RIPE claim net 25.0.0.0/8 as "their own".
This is pretty standard for European /8. 53/8 is yet another example (Germany has moved to five-digit zip codes since that entry was last updated). At a previous job, I tried to fix our netblocks in the ARIN database. It turned out that legal representation in the U.S. was necessary, so it wasn't worth the trouble. Fortunately, ERX cleaned it up for us a few years later. Looks like the legacy /8s still need to be ERXed.
On 15-apr-2007, at 0:49, Florian Weimer wrote:
Ok, I wasn't clear: the problem here is that both ARIN and RIPE claim net 25.0.0.0/8 as "their own".
This is pretty standard for European /8. 53/8 is yet another example
Interesting, the 53 net is also in both whois databases. However, the 25 net is the only one that both RIRs claim in their delegation records available from the FTP servers.
Is it just me or does all of this have the odor of amateur hour around it? Inconsistencies between the various databases, IANA can't make http://www.iana.org/assignments/ipv4-address-space such that it's unambiguously parsable, ARIN backdates some of the address space it gives out, RIPE used to register address space under "UK" while that's not a valid country code (they fixed that last year, though), and so on.
Yes, I agree that it seems amateurish. I think that about 10 years ago a lot of people became satisfied with the status quo and the technology of IANA and the RIRs stagnated. The world moved on around them but you still see things like IANA's non-parseable text file and ARIN's SWIP system using text templates in email messages. RIPE is not that far ahead either, although they have made a bit of effort. 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. At the same time, IANA and the RIRs just keep doing the same old thing as their data and systems slowly rot away. Anyone who has ever had to deal with data cleansing in a corporate environment knows what I mean about data rot. Systems similarly degrade when the world around them changes. For instance, in Victorian times a wonderful home cleaning device was invented called a vacuum cleaner. It worked like a modern pool vacuum in that you pumped the handle to produce suction. It was an amazing device that could clean the dust out of rugs without hauling them outside, hanging them up and beating them. In todays world it is a quaint museum piece because electricity is now ubiquitous. But the device still works today as well as it did in Victorian times. That is how systems degrade. Why doesn't IANA operate a whois server? 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 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? --Michael Dillon
On Apr 15, 2007, at 2:58 PM, <michael.dillon@bt.com> wrote:
And why don't they do all this with some 21st century technology?
Do they have the requisite staff and funding? ----------------------------------------------------------------------- Roland Dobbins <rdobbins@cisco.com> // 408.527.6376 voice Words that come from a machine have no soul. -- Duong Van Ngo
On Sun, 2007-04-15 at 22:58 +0100, michael.dillon@bt.com wrote:
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... 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.
On Sun, 15 Apr 2007, Jim Popovitch wrote:
I'm just trying to get a complete (not constantly changing) list of bogons.
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?
On Sun, 15 Apr 2007, Jim Popovitch wrote:
On Sun, 2007-04-15 at 22:58 +0100, michael.dillon@bt.com wrote:
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...
Here 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.
On Sun, 15 Apr 2007, Jim Popovitch wrote:
On Sun, 2007-04-15 at 22:58 +0100, michael.dillon@bt.com wrote:
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...
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
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. --- If you have further questions it maybe better to send them to me privately and when I'll try to respond and check on the differences if you find something significant. Its also in my plans to write "bogon 2.0" system as I've learned quite a bit about how things should and should not be done in the last 2-3 years so 2nd time around should be much better (and I'm also better programmer as I switched from being operations network engineer who did some programming on side to operations monitoring & other tools programmer). When I get to this project (maybe over the summer), this will include user web interface to see exactly what changes were done each day and exactly why system added or removed particular block(s). -- William Leibzon Elan Networks william@elan.net
On Sun, 15 Apr 2007 michael.dillon@bt.com wrote:
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
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
On Sun, 15 Apr 2007 michael.dillon@bt.com wrote:
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. -- William Leibzon Elan Networks william@elan.net
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
On 16-apr-2007, at 12:51, <michael.dillon@bt.com> <michael.dillon@bt.com> wrote:
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.
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
On Apr 16, 2007, at 2:48 PM, Steve Wright wrote: [...]
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, -- Leo Vegoda IANA Numbers Liaison
On 16-apr-2007, at 14:30, <michael.dillon@bt.com> <michael.dillon@bt.com> wrote:
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.
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.
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
On Mon, 16 Apr 2007 michael.dillon@bt.com wrote:
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.
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.
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
Michael, On Apr 15, 2007, at 2:58 PM, <michael.dillon@bt.com> <michael.dillon@bt.com> wrote:
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
David Conrad wrote: [..]
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.
Competition? How can it be competition when you are at the top of the food chain. Unless I am misunderstanding something completely that is the place that IANA has. IANA has all the address space. It loans chunks of this address space to the RIR's by delegating it to them. Then the RIR's delegate this to LIR's who delegate it to end-users. As such, IANA having a whois server which delegates this address space down to the RIR's would be a great thing to have and also totally logical and in no way in 'competition' with the RIR's. I am also quite sure that none of the membership of those RIR's will complain about this. Do expect people to then, correctly, point their whois client to whois.iana.org for IP addresses, as then those clients can follow the refer: headers down to the RIR's where the real data is.
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.
"Database dumps" similar to what the RIR's also are providing. eg like ftp://ftp.ripe.net/pub/stats But for IANA that would only be delegation points, thus a list of all the blocks IANA has delegated to the RIR's. Same for whois data (aka ftp://ftp.ripe.net/ripe/dbase/split) so one can simply fetch all those inet6num's in one go. Of course that doesn't apply to IANA as the RIR's have that data. In short: please publish inetnum/inet6num delegations from whois.iana.org to the RIR's using refer: headers in the data. On a similar subject, IANA is also a perfect place for an IRR root. Unfortunately only APNIC, RIPE seem to have a non-beta one. ARIN's rr.arin.net seems to be a bit underused. Greets, Jeroen
As I am Chair of the NRO Executive Council this year, I will speak on behalf of the 5 RIRs regarding this matter. The 5 RIRs and IANA have been engaged in discussions regarding the IPv4 file. We are working together on this. In the process we have been doing a lot of cross checking of the data in the file. Ray
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of David Conrad Sent: Monday, April 16, 2007 3:03 PM To: <michael.dillon@bt.com> Cc: nanog@merit.edu Subject: Re: Question on 7.0.0.0/8
Michael,
On Apr 15, 2007, at 2:58 PM, <michael.dillon@bt.com> <michael.dillon@bt.com> wrote:
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
On Sun, 15 Apr 2007, michael.dillon@bt.com wrote:
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. At the
Please do not confuse 'consistent interface' with 'authoritative'.
Why doesn't IANA operate a whois server?
They do. The question you want to ask is "Why doesn't IANA operate a whois server with IP address information?", and the answer to that involves a number of brick walls and bleeding heads over a number of years.
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?
IANA's role in this should be 'Ugh. Here Big Block. Go Talk to RIR.' imo of course ;)
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?
Been There, Done that. See each RIR's FTP site, updated daily. There's even a standardised format between the RIRs, unlike the whois output. --==-- Bruce.
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?
IANA's role in this should be 'Ugh. Here Big Block. Go Talk to RIR.'
I was referring to the cases where they don't say that. For instance, the text file has 4 columns. Address Block and Date are pretty clear and straightforward. The last two fields, however are explicitly ambiguous. One is entitled "Registry - Purpose" and the other is labelled "Notes or Reference". And immediate improvement would be a whois server that serves up 6 data items per entry such as: AddressBlock: 010 Date: Jun 95 Registry: None Purpose: Private Use Notes: Reference: RFC1918 In the case of 7/8, that Notes field could contain a couple sentences to explain the unusual situation of that block. If course, it would be good to add a few other fields there as well, such as Whois: whois://ws.arin.net:43 in order to provide a referral chain as one person mentioned. Or, maybe all this is already defined in the RIR database schemas and IANA should just adopt the same schema. Note that for some blocks, useful additional info could be placed there such as: AddressBlock: 019 Date: May 95 Registry: None Purpose: Direct Assignment Notes: Ford Motor Company Reference: Whois: whois://ws.arin.net:43 FINET which gives the RIR holding additional info and the NetName tag to use when looking it up there. The bottom line is that lots of organizations, not just ISPs, want to see a complete and up-to-date picture of the status of the entire IPv4 space (and Ipv6 space someday) because criminals are using hijacked IP addresses to hide their identities. They believe that the whois directories, collectively, should identify the organization who has administrative control of any IP address and should lead to a technical contact who is ready, willing and able to act when informed about network issues, whether they are abuse issues or some other technical problem. The current whois system has no authoritative root leading to large gaps in the data. And the lack of a root means that the 5 RIRs all do different things, leading to large amounts of garbage data in the system. Even when this data accurately identifies an organization, it often turns out that the organization either doesn't have administrative control over its network or else they have no technical contacts who are ready, willing and able to act when contacted. I believe that fixing the IANA issues will lead to the others being addressed. --Michael Dillon
This posting is not too relevant to the NANOG thread, but there are some places where IMHO the record needs to be set straight: Alexander Harrowell wrote:
025/8 Jan 95 UK Ministry of Defense (Updated - Jan 06)
NetRange: 25.0.0.0 <http://25.0.0.0> - 25.255.255.255 <http://25.255.255.255> CIDR: 25.0.0.0/8 <http://25.0.0.0/8> NetName: RSRE-EXP NetHandle: NET-25-0-0-0-1 Parent: NetType: Direct Assignment NameServer: NS1.CS.UCL.AC.UK <http://NS1.CS.UCL.AC.UK> NameServer: RELAY.MOD.UK <http://RELAY.MOD.UK> Comment: RegDate: 1985-01-28 Updated: 2005-09-06
Ah. I think you'll find this is a result of there being some legacy stuff from before the UK NIC, Nominet, was set up in 1996.
I don't recall this being anything to do with Nominet, which has never had any role in IP address allocation, only .uk domain registration.
Before then, the de facto authority was the academics, JANET, working out of the University of London Computer Centre. Hence cs.ucl.ac.uk <http://cs.ucl.ac.uk> getting in there.
The CS dept at University College London was an ARPA/SATNET research site long before the ULCC/JANET production folks had anything to do with IP in the early 90s. I think you'll find the above reference is to do with early research-project collaborations between UCL-CS and the military RSRE.
There are a few domain names in a similar position - post nominet, the .uk zone was reorganised to assign 2LDs like *.gov.uk
Most of the widely-used 2LDs of .uk existed pre-Nominet.
but there were already a few 1LD .uk assignments, notably mod.uk <http://mod.uk> and parliament.uk <http://parliament.uk>. I'm not sure if it's been cleared up who is responsible for them.
These are documented at: http://www.nominet.org.uk/registrants/sld/registrations/ To an "Internet old fart" like me :-), I think this demonstrates the importance of recording for posterity some of what went down in the early days. For those interested, we've been accumulating a series of presentations at UKNOF meetings about UK Internet history from people who were around during at the time, you can find these at: http://www.uknof.org.uk/history.html (might make sense for any follow-up on this to be on another list, e.g. uknof@uknof.org.uk or nom-steer@nic.uk) Keith ISC/UKNOF
Iljitsch van Beijnum wrote: [..]
Another interesting case:
025/8 Jan 95 UK Ministry of Defense (Updated - Jan 06) [..] I tried emailing RIPE and ARIN. hostmaster@ripe.net returned my message unread and I have no idea what other email adddress to use, hostmaster@arin.net talked at length about cleaning up the legacy A space without actually addressing the issue. Good times.
Use ripe-dbm@ripe.net for all RIPE whois (DataBase Manager - dbm) related issues. Greets, Jeroen
Hi, team. 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, though there is some debate about its allocation status. We're waiting for all of those parties to issue a consistent statement before we make any changes. Thanks, Rob, for Team Cymru. -- Rob Thomas Team Cymru http://www.cymru.com/ cmn_err(do_panic, "Out of coffee!");
Hi, On Apr 14, 2007, at 12:47 PM, Rob Thomas wrote:
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,
Right. Packets sourced out of 7.0.0.0/8 should never be seen on the Internet.
though there is some debate about its allocation status.
Not really. The debate is about how that status should be reflected in the IPv4 registry maintained by IANA. The ARIN data is, as far as I am aware, accurate.
We're waiting for all of those parties to issue a consistent statement before we make any changes.
When we tried to update the IANA registry to reflect what was in the ARIN database, we were told not to. We tried to explain the registration information was already public via ARIN, but were told not to update the IANA registry. IANA and ARIN are working out something to resolve this issue. Rgds, -drc
On 14-apr-2007, at 22:16, David Conrad wrote:
We're waiting for all of those parties to issue a consistent statement before we make any changes.
When we tried to update the IANA registry to reflect what was in the ARIN database, we were told not to. We tried to explain the registration information was already public via ARIN, but were told not to update the IANA registry. IANA and ARIN are working out something to resolve this issue.
And who, exactly, gets to tell IANA/ICANN how to do its job??
On Apr 14, 2007, at 1:31 PM, Iljitsch van Beijnum wrote:
And who, exactly, gets to tell IANA/ICANN how to do its job??
As far as I can tell, pretty much everyone on the planet... :-) More seriously, registrants typically control their registration data. 7.0.0.0/8 is an extreme version of this and is a unique case that has its roots in a historical mistake. As I said, ARIN and IANA are working to remedy the situation. Rgds, -drc
Hi, David.
Not really. The debate is about how that status should be reflected in the IPv4 registry maintained by IANA. The ARIN data is, as far as I am aware, accurate.
Ah, sorry, pardon my misrepresentation. :)
When we tried to update the IANA registry to reflect what was in the ARIN database, we were told not to. We tried to explain the registration information was already public via ARIN, but were told not to update the IANA registry. IANA and ARIN are working out something to resolve this issue.
Great, thanks to all! Thanks! Rob. -- Rob Thomas Team Cymru http://www.cymru.com/ cmn_err(do_panic, "Out of coffee!");
On Sat, 14 Apr 2007, David Conrad wrote:
Hi,
On Apr 14, 2007, at 12:47 PM, Rob Thomas wrote:
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,
Right. Packets sourced out of 7.0.0.0/8 should never be seen on the Internet.
What about BGP routes for it then (see below)?
though there is some debate about its allocation status.
Not really. The debate is about how that status should be reflected in the IPv4 registry maintained by IANA. The ARIN data is, as far as I am aware, accurate.
We're waiting for all of those parties to issue a consistent statement before we make any changes.
When we tried to update the IANA registry to reflect what was in the ARIN database, we were told not to. We tried to explain the registration information was already public via ARIN, but were told not to update the IANA registry. IANA and ARIN are working out something to resolve this issue.
Ok. I'm going to take the above to mean that its not in fact a bogon block and that DoD is correct owner of the block. But as I do have tickets open with both ARIN and IANA, I'll wait a little bet for an answer there before making actual update. The question now still remains regarding 7.1.1.0/24 advertisement. Is it legitimate or an error or something worse? P.S. This advertisement has been around from start of the year, around Jan 15th is I think when it started. Previously I've not seen this block in BGP although it does not mean it did not happen for specific peers who did not pass it along further. -- William Leibzon Elan Networks william@elan.net
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? --Michael Dillon
michael.dillon@bt.com wrote:
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. 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. Greets, Jeroen
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
On Sun, Apr 15, 2007 at 11:25:58PM +0100, michael.dillon@bt.com wrote: ...
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. ...
And what happens if the legitimate owners of those already allocated start advertising routes for them on the public Internet, or IANA decides to release some of those not already allocated? Those NATs, if single-NAT'ed, will find themselves unable to reach those resources. *sigh* In fact, I think I have seen some of those on the public Internet, I could be wrong. -- Joe Yao Analex Contractor
They could always configure destination-based NAT and perhaps "assist" by allocating 10/8 space for those networks if they so choose to reach them! (smirk) Scott -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Joseph S D Yao Sent: Monday, April 16, 2007 7:13 PM To: michael.dillon@bt.com Cc: nanog@merit.edu Subject: Re: Question on 7.0.0.0/8 On Sun, Apr 15, 2007 at 11:25:58PM +0100, michael.dillon@bt.com wrote: ...
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. ...
And what happens if the legitimate owners of those already allocated start advertising routes for them on the public Internet, or IANA decides to release some of those not already allocated? Those NATs, if single-NAT'ed, will find themselves unable to reach those resources. *sigh* In fact, I think I have seen some of those on the public Internet, I could be wrong. -- Joe Yao Analex Contractor
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. ...
And what happens if the legitimate owners of those already allocated start advertising routes for them on the public Internet, or IANA decides to release some of those not already allocated? Those NATs, if single-NAT'ed, will find themselves unable to reach those resources.
In general, there is simply no Internet connectivity for devices on these networks. Not eeven LAN connectivity.
In fact, I think I have seen some of those on the public Internet, I could be wrong.
But it is not a military application so who knows what some of the end users have done with their workstations. There is all kinds of wierd stuff out there. --Michael Dillon
At 06:13 PM 4/15/2007, Jeroen Massar wrote:
michael.dillon@bt.com wrote:
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?
Greets, Jeroen
On Sun, 15 Apr 2007, michael.dillon@bt.com wrote:
10/8 used to be a DoD address block, but it was also used exclusively in their blacker networks and similar non-connected infrastructure.
Er, no, it was the ARPANET's block. (See the Assigned Numbers RFCs up to 990.) Tony. -- f.a.n.finch <dot@dotat.at> http://dotat.at/ FISHER GERMAN BIGHT: SOUTHEAST VEERING SOUTH 3 OR 4, OCCASIONALLY 5. SLIGHT. FAIR. GOOD.
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?
Or better yet, 11/8 (to make 10/7)? Stephen
On Sun, Apr 15, 2007 at 10:58:39PM +0100, michael.dillon@bt.com wrote:
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?
I don't remember the ARPAnet being one of their blacker networks. That was what had 10/8 IP addresses. Now, 10/8 is open for nobody to claim as their own public IP addresses. As I understand it from previous responses, however, 7/8 is being used as such (publicly advertised IP address space, just perhaps not at this time all advertised to the public Internet). -- Joe Yao Analex Contractor
participants (26)
-
Adrian Chadd -
alex＠pilosoft.com -
Alexander Harrowell -
Bruce Campbell -
Chris L. Morrow -
Daniel Senie -
David Conrad -
Florian Weimer -
Iljitsch van Beijnum -
Jeroen Massar -
Jim Popovitch -
Jon R. Kibler -
Joseph S D Yao -
Keith Mitchell -
Leo Vegoda -
michael.dillon＠bt.com -
Paul Vixie -
Ray Plzak -
Rob Thomas -
Roland Dobbins -
Scott Morris -
Sean Donelan -
Stephen Stuart -
Steve Wright -
Tony Finch -
william(at)elan.net