Hi everyone,
We're going to anycast a /24 for some DNS servers (and possibly another UDP based service)[1].
I see that ARIN are listing on https://www.arin.net/knowledge/ip_blocks.html the smallest allocations from each prefix. Will we have trouble getting a /24 announced if we take it from a regular /20?
Or in other words: Do we need to get a block from ARIN from one of the prefixes that they specify they allocate out in /24 chunks?
- ask
[1] For the NTP Pool system - http://www.pool.ntp.org/ - your network probably sent some of the 50-100,000 requests the pool members got this second. And this. And this. ... 
No, you can split up allocations as you want, provided you can prove you
own them.
Some providers however, won't announce anything smaller than a /24.
William
I guess to rephrase my question:
Are there (a significant number of) providers that will filter a /24 announcement from an ARIN prefix not in the list of prefixes where they allocate /24 blocks.
(I take it from what you wrote that the answer is "No").
- ask
I have yet to encounter any. They are "your IPs" as far as they are
concerned, so they'll typically announce whatever you ask as long as
they are "your IPs".
William
Are there (a significant number of) providers that will filter a /24 announcement from an ARIN prefix not in the list of prefixes where they allocate /24 blocks.
Not in my experience, but I don't know how useful that is to know because I don't know how to characterise my experience in any meaningful way 
(I take it from what you wrote that the answer is "No").
I'm interested in the idea of anycasting one of the pool.ntp.org herd-members. Every time I've suggested such a thing I've been told (paraphrasing) that a good (server, client) NTP session exhibits reasonable RTT stability, this constitutes, in effect, a long-lived transaction, and hence anycast is not a good answer unless you have confidence that the potential for oscillations is low, or that the frequency of the oscillations is very low (i.e. in a private network this might be a good answer, but across the public Internet it's a poor answer).
Has the thinking changed, or did I just misunderstand?
Joe
AT&T announces ours. It just took a little bit of prodding to get the sales people to ask the appropriate technical people.
We have a very old ARIN-allocated /24 but we have only one upstream, so we have no AS number of our own.
Everyone: Thanks for the replies regarding the /24 announcement from a "/20 allocated block". Yes, obviously the /20 announcement will handle the traffic, too. I'm a regular reader on NANOG and consistently impressed by the expertise on display and the speed with which it's generously handed out.
I'm interested in the idea of anycasting one of the pool.ntp.org herd-members. Every time I've suggested such a thing I've been told (paraphrasing) that a good (server, client) NTP session exhibits reasonable RTT stability, this constitutes, in effect, a long-lived transaction, and hence anycast is not a good answer unless you have confidence that the potential for oscillations is low, or that the frequency of the oscillations is very low (i.e. in a private network this might be a good answer, but across the public Internet it's a poor answer).
Has the thinking changed, or did I just misunderstand?
I think the thinking on NTP [ see below ] is the same; but indeed when I wrote "possibly other UDP based services" experimenting with that was my idea, too.
I believe some of the CDNs are anycast based (Cachefly?) and they did some extensive tests with very long http transactions. (And I guess do a big test daily in running the service...).
However -- Much of the pool.ntp.org traffic is from SNTP clients where the NTP considerations don't apply. (In summary: SNTP = dumb client that just asks for the time now; NTP = clever server that keeps track of the time. The protocol is the same, but the usage quite different).
- ask
* Ask Bjørn Hansen:
Are there (a significant number of) providers that will filter a /24
announcement from an ARIN prefix not in the list of prefixes where
they allocate /24 blocks.
I've seen such filters applied to RIPE's /8s which actually led to
reachability problems because the shorter covering prefix was not
announced. (Arguably, that's two failures.)