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

[AfriNIC-rpd] Draft Policy: Anycast Assignments in the AfriNIC region

McTim dogwallah at
Mon Nov 26 15:22:08 UTC 2012


My apologies for both not being present in Sudan and for not following
up on this sooner.

I had thought that I had addressed the concerns of the pdwg and edited
the proposal, but in re-reading the minutes and this thread, I see
that there are still some issues outstanding on this draft proposal
that will delay this proposal going to last call.

My questions to the group are:

Do we want to put a numerical limit on the number of /24's that can be
assigned under this proposal?

If so, what should that number be?  The original draft suggested one.
Other numbers are possible.

The original draft also suggested that the assignments come from PA
blocks or end-user space.

Graham has helpfully pointed out that it may be better to have these
blocks be assigned by the NIC from separate blocks, in which case, I
think it would be ok to have a limit of one.  That would mean however
that if an organisation needed more than one, they would have to make
multiple requests.

If the community feels that we should use non-PA space for this, then
should we have the NIC make a reservation of space for this purpose?
If so, how large should it be??

There was also support for adding IPv6 explicitly to this proposal,
which I feel is not needed due to the fact that IPv6 additioanl
allocations don't need to meet the 80% criteria and of course the much
larger address space in v6.

In any case, I am happy to add IPv6 to this proposal, but I need some guidance.

Should these v6 blocks come from PA allocations or from separate
blocks specifically reserved for the purpose?

Should the assignment size in v6 be /48, or do we not need to specify
an assignment size in IPv6??

In other words, the same questions that apply for v4 need to be
addressed (sorry, bad pun) for IPv6.

MJE as co-author is in Khartoum and I will be on Skype and webex
following the discussions.


"A name indicates what we seek. An address indicates where it is. A
route indicates how we get there."  Jon Postel

On Mon, May 7, 2012 at 3:58 AM, Graham Beneke <graham at> wrote:
> Hi
> On 18/04/2012 13:02, Owen DeLong wrote:
>> Having a dozen or so anycast services that each need an address doesn't
>> mean you don't have other things that require unicast addresses. The
>> current policy makes it difficult to deploy both.
> This is a concern I had. It may work to announce a /24 from part of a larger
> aggregate that the LIR hold but there is also a greater chance that these
> are filtered.
> Anycast prefixes are often originated from a different ASN to what is used
> for unicast purposes and many engineers could view this as a hijack.
> I would much prefer that the policy provides a mechanism for an LIR (or
> end-user) to get a new *assignment* for anycast once they have fulfilled the
> requirements. This would be a separate prefix for which utilisation is
> considered separately from any other allocations or assignments as per
> McTim's proposal.
> regards
> --
> Graham Beneke
> _______________________________________________
> rpd mailing list
> rpd at

More information about the RPD mailing list