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

[rpd] Anycast allocations and current policy

Adam Nelson adam at
Sun Feb 8 22:49:21 UTC 2015


Thanks for participating.  Keep in mind that LIRs and end users can still
apply through normal channels for IP space even if the purpose is Anycast.
The Anycast policies provide another channel to Anycast deployments that
might otherwise be difficult to get through the other channels - but those
existing channels are still available.


Kili - Cloud for Africa:
Musings: <>
More Musings:
About Adam:

On Sat, Feb 7, 2015 at 7:32 PM, Seun Ojedeji <seun.ojedeji at> wrote:

> 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)
> Cheers!
> 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
> _______________________________________________
> rpd mailing list
> rpd at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the RPD mailing list