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

[rpd] AnyCast assignments - Update

Frank Habicht geier at
Sat Nov 8 06:28:35 UTC 2014


sorry to come pretty late with this, but maybe better now than never (or

There are 2 ways for anycast deployments:
1. announce and see what happens
2. announce and at some locations limit the scope of the announcements to
only directly peering networks (with the well-known NO_EXPORT community).

By using the 2nd method, some anycast operators differentiate between their
"global nodes" and "local nodes".
see also:

When 2 networks AS1 and AS2 are both connected (and preferring) local
nodes, they will carry the anycast prefix with NO_EXPORT in their network.

A common customer AS3 that is multihomed to both AS1 and AS2 and receiving
"full BGP table" from them, will not receive the anycast prefix. If AS3
doesn't use a default, they will not reach the anycast service.

The original:
Fix by RIPE NCC ("K"):

To avoid this, anycast operators have added an announcement for the
covering /23 from the global nodes. This will always be announced without
NO_EXPORT community, and will thus be visible and reachable to everyone.

I think the same can be expected of anycast operators using this proposed
policy. Therefore I suggest we give them the option to request and receive
either /24 or /23 - their choice.
In IPv6 I also suggest to optionally assign a bigger block than /48.
A /47 would suffice but I guess we don't want to split the nibble into bits ;-)

So I propose to replace every instance of "/24" with "/23 or /24" and
replace every instance of "/48" with "/44 or /48"  - or maybe "/44 up to /48".

Meaning anycast operators can choose which one they request, and they can
get these according to their request.

Sorry for bringing this up that late.


On 11/4/2014 12:06 PM, Mark Elkins wrote:
> I'm happy to make changes along the lines of what Nishal suggested...
> that is:
> Replace:
> 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.
> With:
> These resources must be used for the sole purposes of providing anycast
> services.
> I have been trying to have Ernest update the website - he may have
> malaria again.
> On Mon, 2014-10-20 at 21:45 +0200, Mark Elkins wrote:
>> On Mon, 2014-10-20 at 22:11 +0300, Ernest wrote:
>>>>> 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.
>>>> 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)
>>> As there are no explicitly indicated limitations in the current
>>> policy, we implemented this such that an organization can request
>>> and be granted one /24 *per request*. The frequency of the anycast
>>> requests however (from the same organization) is unlimited per our
>>> interpretation.
>>> While reading through the new proposal - we also interpret it such
>>> that one /24 v4, one /48 v6 prefix and one ASN will be assigned with
>>> *each* anycast request from the same organization, and there is no
>>> limit on the number of times the same org can request such resources.
>> Which should mean there is nothing wrong with the wording!
>> _______________________________________________
>> rpd mailing list
>> rpd at
> _______________________________________________
> rpd mailing list
> rpd at

More information about the RPD mailing list