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...

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:

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?

.. 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

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.

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.

[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 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.

Hi,

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

And who, exactly, gets to tell IANA/ICANN how to do its job??

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. :slight_smile:

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.

As far as I can tell, pretty much everyone on the planet... :slight_smile:

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

* 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.

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.

Hi,

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.

> 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... :slight_smile:

but you never LISTEN! :slight_smile:

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

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

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