Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: NANOG: users

Question on 7.0.0.0/8

 

 

First page Previous page 1 2 3 Next page Last page  View All NANOG users RSS feed   Index | Next | Previous | View Threaded


william at elan

Apr 13, 2007, 8:05 PM

Post #1 of 53 (1375 views)
Permalink
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 [at] nic

--
William Leibzon
Elan Networks
william [at] elan


Jon.Kibler at aset

Apr 13, 2007, 10:27 PM

Post #2 of 53 (1356 views)
Permalink
Re: Question on 7.0.0.0/8 [In reply to]

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 [at] nic
>

--
Jon R. Kibler
Chief Technical Officer
Advanced Systems Engineering Technology, Inc.
Charleston, SC USA
(843) 849-8214


adrian at creative

Apr 14, 2007, 2:20 AM

Post #3 of 53 (1336 views)
Permalink
Re: Question on 7.0.0.0/8 [In reply to]

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


william at elan

Apr 14, 2007, 2:20 AM

Post #4 of 53 (1352 views)
Permalink
Re: Question on 7.0.0.0/8 [In reply to]

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 [at] nic


iljitsch at muada

Apr 14, 2007, 2:40 AM

Post #5 of 53 (1339 views)
Permalink
Re: Question on 7.0.0.0/8 [In reply to]

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 [at] ripe returned my
message unread and I have no idea what other email adddress to use,
hostmaster [at] arin talked at length about cleaning up the legacy A
space without actually addressing the issue. Good times.


a.harrowell at gmail

Apr 14, 2007, 3:16 AM

Post #6 of 53 (1351 views)
Permalink
Re: Question on 7.0.0.0/8 [In reply to]

On 4/14/07, Iljitsch van Beijnum <iljitsch [at] muada> 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.


iljitsch at muada

Apr 14, 2007, 3:54 AM

Post #7 of 53 (1355 views)
Permalink
Re: Question on 7.0.0.0/8 [In reply to]

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.


jeroen at unfix

Apr 14, 2007, 6:13 AM

Post #8 of 53 (1340 views)
Permalink
Re: Question on 7.0.0.0/8 [In reply to]

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 [at] ripe returned my message
> unread and I have no idea what other email adddress to use,
> hostmaster [at] arin talked at length about cleaning up the legacy A
> space without actually addressing the issue. Good times.

Use ripe-dbm [at] ripe for all RIPE whois (DataBase Manager - dbm)
related issues.

Greets,
Jeroen
Attachments: signature.asc (0.30 KB)


robt at cymru

Apr 14, 2007, 12:47 PM

Post #9 of 53 (1336 views)
Permalink
Re: Question on 7.0.0.0/8 [In reply to]

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!");


drc at virtualized

Apr 14, 2007, 1:16 PM

Post #10 of 53 (1359 views)
Permalink
Re: Question on 7.0.0.0/8 [In reply to]

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


iljitsch at muada

Apr 14, 2007, 1:31 PM

Post #11 of 53 (1335 views)
Permalink
Re: Question on 7.0.0.0/8 [In reply to]

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


robt at cymru

Apr 14, 2007, 1:40 PM

Post #12 of 53 (1340 views)
Permalink
Re: Question on 7.0.0.0/8 [In reply to]

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!");


drc at virtualized

Apr 14, 2007, 2:10 PM

Post #13 of 53 (1338 views)
Permalink
Re: Question on 7.0.0.0/8 [In reply to]

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


fw at deneb

Apr 14, 2007, 3:49 PM

Post #14 of 53 (1341 views)
Permalink
Re: Question on 7.0.0.0/8 [In reply to]

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


fw at deneb

Apr 14, 2007, 4:27 PM

Post #15 of 53 (1334 views)
Permalink
Re: Question on 7.0.0.0/8 [In reply to]

* Rene Huizinga:

> Well, at least is is still somehow with the same party...

Not quite. The organization formerly known as "debis" is now called
"T-Systems".

> Arin states 'Mercedes Benz AG', RIPE 'Daimler Chrysler'... One would
> think this would/should actually be just the other way around, but
> never mind :)

"Daimler Benz AG" would have been more appropriate. Mercedes Benz was
just the car manufacturer--but I'm not sure if the split was there in
1992.

Until about a year ago, T-Systems actually used parts of the netblock
for some hosted servers (Deutsche Post, for instance). But in the
meantime, they've got non-legacy address space and are no longer in
the "extra-small" category as far as their RIPE membership is
concerned.


iljitsch at muada

Apr 14, 2007, 5:36 PM

Post #16 of 53 (1342 views)
Permalink
Re: Question on 7.0.0.0/8 [In reply to]

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.


william at elan

Apr 14, 2007, 5:50 PM

Post #17 of 53 (1354 views)
Permalink
Re: Question on 7.0.0.0/8 [In reply to]

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 [at] elan


william at elan

Apr 14, 2007, 6:23 PM

Post #18 of 53 (1357 views)
Permalink
RE: Question on 7.0.0.0/8 [In reply to]

On Sun, 15 Apr 2007, Huizinga, Rene wrote:

> BTW, on the same line what's going on with 180.190.0.0/16 actually ?
> It's within the 176.0.0.0/5 registered as Bogon.
> Is it a typo (thai-po ? :P ) from an Asian guy (AS24003 originated) or did I
> miss something lately...? :P

I already dealt with 180.190.0.0/16. Here is response:

| Date: Sat, 14 Apr 2007 11:51:43 +0530
| Subject: Re: bgp bogon announcements if iana space from AS24003
|
| I'll check who is doing this annoucement and get it turned off fastest.
|
| Thanks
| Samod Babu
| Sr. Manager-IT
...
| > 180.190.0.0/16 ## AS24003 : :
| > 180.0.0.0 - 180.255.255.255 ## Bogon (unallocated) ip range
| | Would you guys mind turning it off or if not explaining on nanog and
| other mail lists why you're doing it. Thanks.

--
William Leibzon
Elan Networks
william [at] elan


vixie at vix

Apr 14, 2007, 6:34 PM

Post #19 of 53 (1339 views)
Permalink
Re: Question on 7.0.0.0/8 [In reply to]

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

but you never LISTEN! :-)


michael.dillon at bt

Apr 15, 2007, 2:58 PM

Post #20 of 53 (1339 views)
Permalink
RE: Question on 7.0.0.0/8 [In reply to]

> 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 at bt

Apr 15, 2007, 2:58 PM

Post #21 of 53 (1336 views)
Permalink
RE: Question on 7.0.0.0/8 [In reply to]

>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


jeroen at unfix

Apr 15, 2007, 3:13 PM

Post #22 of 53 (1340 views)
Permalink
Re: Question on 7.0.0.0/8 [In reply to]

michael.dillon [at] bt 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
Attachments: signature.asc (0.30 KB)


rdobbins at cisco

Apr 15, 2007, 3:19 PM

Post #23 of 53 (1331 views)
Permalink
Re: Question on 7.0.0.0/8 [In reply to]

On Apr 15, 2007, at 2:58 PM, <michael.dillon [at] bt> 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 [at] cisco> // 408.527.6376 voice

Words that come from a machine have no soul.

-- Duong Van Ngo


jimpop at yahoo

Apr 15, 2007, 3:25 PM

Post #24 of 53 (1348 views)
Permalink
RE: Question on 7.0.0.0/8 [In reply to]

On Sun, 2007-04-15 at 22:58 +0100, michael.dillon [at] bt 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-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.


michael.dillon at bt

Apr 15, 2007, 3:25 PM

Post #25 of 53 (1355 views)
Permalink
RE: Question on 7.0.0.0/8 [In reply to]

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

First page Previous page 1 2 3 Next page Last page  View All NANOG users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.