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

[rpd] AnyCast assignments - Update

Nishal Goburdhan nishal at
Fri Oct 10 14:34:59 UTC 2014

On 09 Oct 2014, at 5:08 AM, Mark Elkins <mje at> wrote:

> Hello community,

hi mark,

> 3) Proposal
> AFPUB-2012-V4-001 is modified from the original version to the
> following version:
> ...........................................................
> 1. Summary of the problem being addressed by the policy proposal
> This proposal allows an organization to receive an IPv4/IPv6
> allocation or assignment and an AS Number purely for anycast or GPRS
> Roaming Exchange (GRX) usage.
> 2. Summary of how this proposal addresses the problem
> This proposal allows the use of:
> a. One (1) /24 of IPv4 for anycast services from a PA allocation of
> an LIR or direct end-user assignment.
> b. One /48 of IPv6 for anycast services from an IPv6 LIR allocation
> or direct end-user assignment.
> c. An AS Number for anycast purposes.

i'd like some clarification on the (1)x  /24.
specifically, i would like to ensure the following: 
* legitimate operators are able to get resources for anycast;  (the existing policy does this already, so nothing needed here, great !)
* there is no limitation made to AfriNIC allocating _only_ a single block for anycast.

let me explain the second request.  
the policy, as is worded, is potentially ambiguous.  hostmasters _may_ be tempted to say that, as per policy, they have satisfied the requirement to allocate one, and only one prefix for anycast purposes, to an organisation, when, a forward thinking organisation might wish to have more than one anycast cloud.  while having one prefix, is obviously better than zero, it would be _wrong_ to limit this to just one anycast cloud.  

so, while the current policy doesn't _disallow_ more than a single allocation, it's not clear (i think) to the hostmaster team, that more than one allocation might be allowed.
(i guess, the other way of looking at this, is that there is no requirement to _change_ policy if, there is acknowledgement from the hostmaster team that they understand this - perhaps we can get them to comment here.  the task of determining valid usage will still be up to the hostmasters of course)

> AFRINIC staff will consider anycast IPv4/IPv6 blocks assigned to be
> "fully utilised" by the LIR when considering utilisation for first
> allocation or for an additional allocation to an LIR.
> 3. Proposal
> 3.1 An organization may obtain one (1) /24 IPv4 and/or one (1) /48
> IPv6 prefix for anycast or GRX purposes from an allocation or an
> AFRINIC issued direct end-user assignment. An AS Number should also
> be issued for the same purposes if requested. These resources must
> be used for the sole purpose of anycasting web or authoritative DNS
> servers as described in BCP126/RFC 4786
> ( or for GPRS Roaming Exchange.
> The IPv4/IPv6 prefixes will count as being fully utilised when an
> organization applies for additional resources. The utilization
> criteria that apply to all IPv4 and IPv6 initial allocation or
> assignment requests shall be waived for anycast assignment requests.

i would like you to remove the words:  "sole purpose of anycasting web or authoritative DNS..." since there are other services that someone might want to anycast, and restricting this to two protocols, is, well...quite limiting ... and, i don't think that policy should limit innovation.
i think what you likely mean is:  "solely for anycast" .. which is subtly different.  i suggest:
"These resources must be used for the sole purposes of providing anycast services".  
(i would even remove the reference to BCP126;  that's an operational thing...)

that aside - i _support_ the change to policy to include IPv6 and an ASN as part of the anycast assignment.
thanks for fix^H^H^H updating this.

> 3.2 Blocks used for anycast services cannot be further assigned or
> sub-allocated. They shall be tagged with the status attribute in the
> AFRINIC whois service as "ASSIGNED ANYCAST".
> 4.0 Revision History
> Version 00 Submitted 2014-10-07 by author.

More information about the RPD mailing list