Since I've just run into the second of these in as many weeks, I thought this was perhaps worth a mail to the list. EP.NET assign netblocks from 198.32/16 to various Internet infrastructure providers, including exchange points and prominent (e.g. ccTLD) nameservers. And maybe other things, for all I know, ask Bill, but definitely not just for exchange points. I realise that answers from the usual whois servers in response to questions within this netblock may not make this obvious. Many ISPs have import policies which reject exchange point blocks from external peers, for which there are many fine and logical arguments. Several of those ISPs reject "198.32.0.0/16 le 24" as part of that policy, however, believing that 198.32.0.0/16 is only used for exchange point assignments. 198.32.0.0/16 is used for other things, too. Not just exchange points. People who need to block exchange point blocks in their import policy would do well to enumerate the specific subnets of 198.32.0.0/16 which are used at exchange points they connect to, rather than denying all routes covered by the /16. Examples of nameservers that fall victim to over-zealous filtering of 198.32/16 assignments are as follows (these are just those present as glue in the root zone): [jabley@halibut]% dig @192.5.5.241 . axfr | grep 198.32 NS1.DNS.AQ. 172800 IN A 198.32.71.12 MZIZI.KENIC.OR.KE. 172800 IN A 198.32.67.9 FLAG.EP.NET. 172800 IN A 198.32.4.13 L.ROOT-SERVERS.NET. 3600000 IN A 198.32.64.12 NS1.2DAY.CO.NZ. 172800 IN A 198.32.66.12 [jabley@halibut]% If you can't traceroute to those nameservers, it would be great if you could patch up your import filters so that they become reachable to your users and customers. [ISC doesn't use any EP.NET netblocks, but we have friends who do.]