Jon et al,
First I appreciate your message that you sent to us at NASA late Friday
regarding a new address block that you received from ARIN. In that message
you suggest that the issue was a BOGON route filter that had not been
updated. Then without allowing sufficient time to respond to your message
(you sent it to an administrative account and not the NOC) you decided to
flame NASA.
You could reach MANY NASA locations, but those at one particular center,
and that issue was related to a firewall update at ONLY one particular
center. This filter was placed in after August when the cental bogon was
removed at the ingress to the network.
If you feel that you have any issue reaching a NASA resource then you can
send a message to noc@nisn.nasa.gov and/or the tech/org/noc POC on any
address space. NISN is NASA's ISP and as such announce via AS297 that
address space.
Now, how can we force that? Sufficient reward for doing so, or
pain for failure. Evidently "some people can't reach you" isn't
enough pain, and having full reachability isn't enough reward.
I think the only way that's relatively guaranteed to be effective is to
move a critical resource (like the gtld-servers) into new IP blocks when
previously reserved blocks are assigned to RIR's.
I still have a couple hundred thousand IPs to check (I'm going to step up
the pace and see if I can get through the list today), but I already have
a list of several hundred IPs in networks that ignore 69/8. The list
includes such networks as NASA, the US DoD, and networks in China, Russia,
and Poland. Those are just a few that I've done manual whois's for.
I haven't decided yet whether I'll send automated messages to all the
broken networks and give them time to respond and fix their filters, or
just post them all to NANOG when the list is complete.
Are people interested in seeing the full list (at least the ones I find)
of networks that filter 69/8?
Does Atlantic.Net get an ARIN discount for doing all this leg work? 
First I appreciate your message that you sent to us at NASA late Friday
regarding a new address block that you received from ARIN. In that message
you suggest that the issue was a BOGON route filter that had not been
updated. Then without allowing sufficient time to respond to your message
(you sent it to an administrative account and not the NOC) you decided to
flame NASA.
My mention of NASA wasn't meant at all as a flame. It was just an example
that not all the networks with outdated filters are remote nets in far
away countries that my customers wouldn't care about. A few I've
found are. I had to look up the country code to find that .al is Albania.
I had actually planned to mention at some point that NASA was the first
(only so far) network to respond to the few messages I sent out late last
friday, and that their reported network has already been fixed. I can
only assume that none of the previous 94 allocation holders of 69/8 space
noticed or complained to the right people.
If you feel that you have any issue reaching a NASA resource then you can
send a message to noc@nisn.nasa.gov and/or the tech/org/noc POC on any
address space. NISN is NASA's ISP and as such announce via AS297 that
address space.
As for sending the message to the wrong addresses, I can only suggest
updating your ARIN info. I sent the message to all the POCs (except the
abuse one) for the relevant NetRange. This is what I'll be doing when I
send out the automated messages. The ones sent friday were done by hand.
Can you elaborate on how a firewall config was the problem? If whatever
was done there is commonly done, it may be worth revising my form message
before I send out a large number of them.
Once upon a time, Michael Whisenant <michael@whisenant.net> said:
You could reach MANY NASA locations, but those at one particular center,
and that issue was related to a firewall update at ONLY one particular
center. This filter was placed in after August when the cental bogon was
removed at the ingress to the network.
The same can be said of many large organizations.
If you feel that you have any issue reaching a NASA resource then you can
send a message to noc@nisn.nasa.gov and/or the tech/org/noc POC on any
address space. NISN is NASA's ISP and as such announce via AS297 that
address space.
ARIN shows some rather outdated information for some NASA blocks. For
example, 192.112.230.0/24 still has area code 205 and lists an email
address with a server that no longer exists. The info listed for
192.112.220.0/22 & 192.112.224.0/20 lists "dns.support@nasa.gov" for the
tech contact.
When doing work like this, people are not likely to look in BGP to find
the AS announcing a block and then contact that AS; many ISPs announce
blocks on behalf of their customers and are not necessarily interested
in hearing that a customer has a bogus bogon list.
This isn't meant to be a pick on you (we've got some SWIPs filed
incorrectly that we are working on). I've just run into more and more
cases where ARIN (or other RIR, but I'm typically interested in ARIN
info) info is out of date. Maybe ARIN should periodically send an "are
you there" type email to contacts (like some mailing lists do). If that
fails, mail a letter with instructions on how to update your contact
info, and if that fails, delete the invalid contact info - I'd rather
see no contact info than bogus info.
Well Jon,
I spent some time reading your message below, and trying to look
at if I experienced the issue, just what I would have done differently, or
what would have been more meaningful in your initial email blast... Here
are some of my thoughts...
First since you are taking the time to explore where your routes
are reaching, why not send the end user (yes your approach contacts the
end user of the IP addres block not the network provider) a traceroute
showing where the problem is first encountered? Now granted some places
may filter ICMP messages, but it is some more information from which the
end user can start addressing the problem?
Next I would suggest that you look at the tone of your message to
make sure that the reader understands that you have an issue and that you
would like his assistance. Sometimes emails can be viewed as HARSH when
they are meant to be informative and helpful in getting the issue
corrected.
I would personally have run a traceroute with the NANOG traceroute
and also copied the Network ASN where the packets seems to have stopped.
After all that is the most likely source of the filter, right? When I
received your original message that is the first think that I did from an
off network account. You mention that we should update our ARIN listing...
well I do not disagree, but the subnet where the packets stopped would
have had a noc email with 24x7 number to call. Then again so would have
the ASN where the traceroute stopped.
Yes I think that there is interest in understanding new subnet
allocations have universal routing. Clearly in this case when addressing
was first allocted in Aug 2002 this should have become and issue by now...
You suggest that ARIN should do more (lets expand this to any RR), what
would you suggest they do? Do you plan to be at the ARIN meeting in April?
We would welcome your views on this topic be addressed... Take it to a
ARIN advisory council member if you do not plan to attend, they can
champion your cause... they do it well...