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

[rpd] RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space AFPUB-2019-GEN-006-DRAFT02

Ben Maddison benm at
Mon Feb 15 18:12:14 UTC 2021

Hi Patrick,

On 02/13, Patrick Okui wrote:

> On 13 Feb 2021, at 16:26 EAT, Ben Maddison via RPD wrote:


> > At time t2, the RIR re-allocates 2001:db8:foo::/48 to member Y, who also

> > has AS65001.

> > Member Y issues ROA:

> > 2001:db8:baa::/48 asID:65001


> Bad things will always happen if member Y attempts to create a ROA different

> from what they were allocated.


> If I understand correctly at time t2 2001:db8:baa::/48 is still legitimately

> allocated to AS65000.

I don't think that you got the point that I was trying to make.
Apologies if my explanation was unclear.

The hypothetical timeline is:
t0: AS65000 has 2001:db8:f00::/48, and has issued a ROA for it, and
originates it in BGP;
t1: The allocation of 2001:db8:f00::/48 is revoked (why is not
important). The RIR shrinks the resources on the member CA cert,
making the AS65000 ROA "disappear".
t2: AS65001 receives 2001:db8:f00::/48, and issues a new ROA (with
asID:65001), and begins originating the prefix in BGP.

The bit that this policy adds is that at t1 the RIR would also issue an
AS0 ROA for the prefix.

The point I was making is that this only changes the validation status
of a bogon announcement during the interval t1-t2.
After t2, the newly issued ROA (with asID:AS65001) is sufficient to make
any lingering bogon announcements ROV-Invalid. The presence, or not, of
an AS0 ROA becomes irrelevant.

Thus, any suggestion that this policy makes *re-allocation* of resources
easier is bogus. It *only* helps to clean up bogons.

Hope that makes more sense?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <>

More information about the RPD mailing list