Hi.
We've recently been allocated address space out of 59.0.0.0/8, which
was released to APNIC by IANA about 11 months ago.
Prior to that release, it was reserved, and appeared on all the public
bogon filtering lists.
It obviously isn't supposed to appear on them anymore.
If you run any bogon filtering, can you please check your border ACLs
and BGP prefix filters to ensure that you're no longer preventing
access to 58.0.0.0/8 or 59.0.0.0/8 ?
Thanks,
- mark
Further to this:
If anyone from EV1 hosting is reading this, please get in touch ASAP?
We've been talking to a few of your front-line tech support people
for a couple of days now, and while it's been fun, we'd kinda like to
stop doing that and start talking to someone who acknowledges that
there's a problem here and knows how to fix it 
Thanks,
- mark
Hi, NANOGers.
] If you run any bogon filtering, can you please check your border ACLs
] and BGP prefix filters to ensure that you're no longer preventing
] access to 58.0.0.0/8 or 59.0.0.0/8 ?
Folks can keep up with the bogon filters through a wide variety of
means. We have HTTP, DNS, RADb objects, RIPE NCC objects, and
text files.
<http://www.cymru.com/Bogons/>
It can be even easier still! Why not automate the process of
bogon filter updates, thus avoiding the shame of filtering good
folks such as Mark? Take a peek at our Bogon route-server
project at the following URL.
<http://www.cymru.com/BGP/bogon-rs.html>
Thanks,
Rob, for Team Cymru.
I think this has been posted here more than a few dozen times. Perhaps a
list of sites/Nocs that do not automate their updates could be kept so:
1. People would have a list of phone numbers to call every time a change
was made.
2. People would have a list of sites that were known to be of less
clue than most. This might help them make purchasing decisions in the
future.
> Folks can keep up with the bogon filters through a wide variety of
> means. We have HTTP, DNS, RADb objects, RIPE NCC objects, and
> text files.I think this has been posted here more than a few dozen times. Perhaps a
list of sites/Nocs that do not automate their updates could be kept so:1. People would have a list of phone numbers to call every time a change
was made.2. People would have a list of sites that were known to be of less
clue than most. This might help them make purchasing decisions in the
future.
Hmmmm, one wonders if the static security template has over time become
responsible for more realized loss of connectivity than the attacks it
theoretically protects against.
Perhaps it should be distributed with only a martian and RFC1918 filter,
and not the unallocated space, if everybody knows that people apply it in
a write once configuration manner.
Mike.
+----------------- H U R R I C A N E - E L E C T R I C -----------------+
or there's always that internet drivers license concept... except you'd
need a new class to take care of 'network operators', like 'limo' or 'bus'
citations on car licenses.
Seriously though, Perhaps Puck.nether.net or Mr. Lewis's 69box could be a
good site to host 'slow filter updaters' contact infos?
2. People would have a list of sites that were known to be of less
clue than most. This might help them make purchasing decisions in the
future.
Are you suggesting that NANOG should publish a set
of operational best practices and then only offer
the NANOG seal of approval to companies which adhere
to those best practices?
If there is one thing that will stop telecoms regulators
from attempting to regulate the Internet, it is this.
The technical term is "industry self regulation".
--Michael Dillon
In my experience with 69/8, most of the problem sites were "end users"
rather than service providers...though in some cases, those end users were
things like parts of the US Military and NASA, etc. The only provider I
remember running into that had a static bogon issue was fast.net, but they
don't even exist anymore AFAIK, as they were bought by USLEC.
So while the list would be useful as a contact list for those affected, I
doubt it's going to influence anyone's transit buying decisions.
> 2. People would have a list of sites that were known to be of less
> clue than most. This might help them make purchasing decisions in the
> future.Are you suggesting that NANOG should publish a set
of operational best practices and then only offer
the NANOG seal of approval to companies which adhere
to those best practices?
The Good Netkeeping Seal of Approval, yes.
If there is one thing that will stop telecoms regulators
from attempting to regulate the Internet, it is this.
The technical term is "industry self regulation".
And it would have the side effect of assembling all of those best
practices in a central place where those occasaional operators of
really small networks (like me who care what they are can
conveniently find them.
I'd recommend a wiki. Running MediaWiki.
But then, I recommend that for all centralized knowledge capture
situations.
Cheers,
-- jra
And it would have the side effect of assembling all of those best
practices in a central place where those occasaional operators of
really small networks (like me
conveniently find them.I'd recommend a wiki. Running MediaWiki.
Well, its not running MediaWiki at the present time, but anyone is welcome to add this kind of useful content to the BGP4.net wiki. http://www.bgp4.net