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

[AfriNIC-rpd] AFPUB-2006-GEN-001 and Anycast

Mauritz Lewies mauritz at
Tue Mar 27 14:53:56 UTC 2012


Ok fair point so let me explain as this is the key point for why I suggested the amendment.

Lets assume that the technical values and requirements for Anycast is valid..

The current requirements for a minimum ipv4 allocation of /24 is that the requester can prove that they will be able to utilise a minimum of /25. This is to encourage end users to rather use space allocated by their ISPs.

However the technical requirements for Anycast can not be bound by a /25 limitation. An Anycast service can be delivered using a lot less address space than a /25. But the limitation of a /24 in the ISP realm can not be altered.

Thus given the current requirements (minimum of /25), I either need to fabricate address use up to a /25 and show Serial numbers of devices (which given virtualisation is easy to confuse) or a simple addition to the policy will allow /24s to be allocated to SaaS or NaaS providers with a valid Anycast design and need.

Sent from my iPad

On 27 Mar 2012, at 15:09, Alan Barrett <apb at> wrote:

> On Tue, 27 Mar 2012, Mauritz Lewies wrote:
>>>> Often Service providers (SaaS, NaaS) have needed IP space to deliver Anycast based services and due to the lack of a stipulation for Anycast have had to fabricate information to meet the criteria.
>>> It's impossible to "fabricate information to meet the criteria".  If any information associated with your application is fabricated, then your application is not valid.
>> I don't agree, who checks the information supplied? Eg serial numbers and performance stats of servers? With virtualisation will Afrinic decide if a micro server can run 124 VMs or 2? Will I really run 8 netflow collectors in VM? So then who decides if my application is not valid?
> I was speaking about what the rules are, not about whether or not breach of the rules will be detected and punished.
> You can fabricate information to pretend to meet the criteria, but you can't fabricate information to really and truly meet the criteria.
>>>> Thus I suggest that the policy be amended to include "d) Provide a technically sound Anycast design."
>>> What exactly is the problem here?  Can you give real or theoretical examples of technically sound Anycast designs that do not meet the existing criteria?
>> Any NaaS or SaaS provider that is limited to deploying IP based services (i.e. Not DNS or Appliance based) will likely need Anycast.  Redundancy via cloud-based systems will involve deploying an Anycast based model.  One example would be to deploy servers in DCs in South Africa, Nigeria and Kenya, Anycast will allow for redundancy and proximity to services.
>> Example:  1. Various African ISPs do not allow core routing/switching platforms to make use of DNS lookups. How will you provide redundancy for syslog/snmp traps/VTY ACLs/AAA//DNS SEC, Auth and cache etc etc if you were a SaaS provider of these platforms?
> You haven't answered the question.  Or at least, I am unable to see an answer.  How does your anycast deployment fail to meet AfriNIC's existing criteria?
> Let me try using different words.
> If you have a certain number of servers in certain locations, the you can quaify for a certain number of IP addresses.  Is that not good enough?  What's special about anycast in this context that would make you qualify for less address space than if you did not use anycast?
> --apb (Alan Barrett)
> _______________________________________________
> rpd mailing list
> rpd at

More information about the RPD mailing list