Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[rpd] Anycast allocations and current policy

Seun Ojedeji seun.ojedeji at
Sun Feb 8 00:32:46 UTC 2015

Hi Jerome,

There is a related policy awaiting board ratification which you may want to
look at and then propose an update through following the normal PDP (policy
development process)


sent from Google nexus 4
kindly excuse brevity and typos.
On 7 Feb 2015 06:37, "Jérôme Fleury" <jerome at> wrote:

> Hi everyone,
> I'm new to this mailing-list, so please pardon any misstep.
> While I have been searching discussions on this matter in this
> mailing-list, I have been unable to find an adequate answer.
> I'd like to discuss the relevance of AFPUB-2012-V4-001
> (
> ).
> In summary, it prevents companies operating anycast CDN (like mine)
> from requesting anycast allocations to Afrinic because allowing only a
> /24 per allocation is insufficient to meet our current expansion
> needs.
> Our service currently runs fully on anycast, and we use 4 times more
> anycast addresses than unicast ones. We could like to expand our
> service in Africa.
> While having policies to discuss anycast is very much needed and
> welcome, I don't agree with the following:
> "In addition, current anycast practice announces an entire /24.
> AFRINIC current IPv4 policy states that the minimum allocation size on
> initial allocation is a /22. To use a /22 for anycast when you
> potentially are only using a few addresses in the block is wasteful."
> - While it's true that a lot of anycast prefixes seen in the global
> routing table are /24s (for traffic-engineering purpose), this should
> not be considered as a basis for this policy. I can certify that a lot
> of anycast prefixes are more than /24s; for example, we advertise
> /20s.
> - Announcing "bigger than a /24 is wasteful" is not true in our case.
> When we advertise a /20 for anycast purpose, we make sure that each
> and every one of the addresses are used for production traffic. When
> you serve millions of websites on your infrastructure, I can assure
> you that you don't waste addresses.
> After this discussion from 2007
>, there hasn't
> been much further discussion since. The anycast world has changed a
> lot in the meantime and in my opinion this policy should be amended to
> reflect today's reality of anycast addressing.
> I welcome thoughts and comments.
> _______________________________________________
> rpd mailing list
> rpd at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the RPD mailing list