Dear all,

I've reviewed the proposal, and while I haven't yet made up my mind
whether this is a good or bad idea, I do want to propose some changes
to the text because the current wording introduces some confusion in my
operator mind.

On Thu, Aug 22, 2019 at 11:52:13AM +0600, Sumon Ahmed Sabir wrote:
> A new version of the proposal "prop-132: AS0 for Bogons"
> has been sent to the Policy SIG for review.
> Information about earlier versions is available from:

Attached is a rewrite of prop-132-v002 ('prop-132-v003.txt') where the
word "bogon" has been mostly replaced with (in my mind) more descriptive

The reason for wording things a bit different is that when I first heard
about this proposal I thought the idea was to create ROAs for bogons
such as RFC 1918 space, and thought "THEY WHAT NOW?!" :-)

If we think in Venn diagrams, indeed, "bogons" contain all "unallocated
and unassigned APNIC address space", and "unallocated and unassigned
APNIC address space" are "bogons", but "bogons" to many operators means
much more than just the APNIC managed portion of it.

A clear advantage of ensuring unassigned or unallocated address space is
not in use by unauthorized parties is that such address space can be
assigned to eligible APNIC members instead. This proposal may (slightly)
increase the pool of available IP address space for the APNIC community.

Kind regards,


prop-132-v003: RPKI ROAs for unallocated and unassigned APNIC address space 


Proposer: Aftab Siddiqui

1. Problem statement
Address space managed by APNIC which has is either "Unallocated" or
"Unassigned" is considered "Bogon address space". Bogons are defined in
RFC3871, A "Bogon" (plural: "bogons") is a packet with an IP source address in
an address block not yet allocated by IANA or the Regional Internet Registries
(ARIN, RIPE NCC, APNIC, AFRINIC and LACNIC) as well as all addresses reserved
for private or special use by RFCs.

As of now, there are XXX IPv4 and YYY IPv6 routes in the global Internet
routing table which cover address space managed by APNIC, but which is not
allocated or assigned by APNIC. In the past, several attempts have been made
to filter out such bogons through various methods such as static filters and
updating them occasionally but it is hard to keep an up to date filters,
TeamCymru and CAIDA provides full bogon list in text format to update such
filters. TeamCymru also provides bogon BGP feed where they send all the bogons
via a BGP session which then can be discarded automatically. Despite these
attempts, the issue of unauthorized adverisments of APNIC's address space
hasn't be resolved so far.

2. Objective of policy change
The purpose of creating RPKI ROAs with Origin AS 0 for APNIC's unallocated and
unassigned address space is to restrict the propagation of BGP announcements
covering such bogon space. When APNIC issues a ROA with AS 0 for unallocated
address space under APNIC's administration, BGP announcements covering this
space will be marked as Invalid by networks doing RPKI based BGP Origin
Validation using APNIC's TAL.

Currently, in the absence of any ROA, these bogons are marked as NotFound.
Since many operators have implemented ROV and either planning or already
discarding Invalid, then all the AS0 ROAs which APNIC will create for
unallocated address space will be discarded as well.

3. Situation in other regions
No such policy in any region at the moment.

4. Proposed policy solution
APNIC will create AS0 (zero) ROAs for all the unallocated and unassigned
address space (IPv4 and IPv6) for which APNIC is the current administrator. Any
resource holder (APNIC member) can create AS0 (zero) ROAs for the resources
they have under their account/administration.

A RPKI ROA is a positive attestation that a prefix holder has authorised an AS
to originate a route for this prefix whereas, a RPKI ROA for the same prefixes
with AS0 (zero) origin shows negative intent from the resource holder that they
don't want to advertise the prefix(es) at this point but they are the rightful

Only APNIC has the authority to create RPKI ROAs for address space not yet
allocated to the members and only APNIC can issue AS0 (zero) RPKI ROAs. Once
they RPKI ROA is issued and APNIC wants to allocate the address space to its
member, simply they can revoke the RPKI ROA and delegate the address space to
members. (this proposal doesn't formulate operational process).

5. Advantages / Disadvantages

Network operators who implement RPKI based Origin Validation and discard BGP
announcements with RPKI state "invalid", will automatically discard BGP
announcements covering unallocated & unassigned APNIC address space. Ensuring
unallocated or unassigned address space is not usable by unauthorized parties
makes more address space available for those who qualify to receive an
allocation or assignment from APNIC.


No apparent disadvantage

6. Impact on resource holders
No impact to APNIC or respective NIR resource holders not implementing ROV.
Those implementing ROV and discarding the invalids will not see any bogons in
their routing table.

7. References
RFC6483 -
RFC6491 -
RFC7607 -
*              sig-policy:  APNIC SIG on resource management policy           *
sig-policy mailing list

Reply via email to