Search RPD Archives
[rpd] RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space AFPUB-2019-GEN-006-DRAFT02
benm at workonline.africa
Mon Feb 15 18:12:14 UTC 2021
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...
Size: 833 bytes
Desc: not available
More information about the RPD