IMHO, while I’m perfectly fine with APNIC administering this and maintaining the ROAs, etc., I believe that the decision to allocate AS0 to this purpose and documentation of this intent should be done through the IETF and be documented in an STD or RFC.
I support the idea, but I believe the proper place to start is the IETF. Owen > On Aug 9, 2019, at 3:01 AM, Sumon Ahmed Sabir <[email protected]> wrote: > > > Dear SIG members, > > The proposal "prop-132-v001: AS0 for Bogons" has been sent to > the Policy SIG for review. > > It will be presented at the Open Policy Meeting at APNIC 48 in > Chiang Mai, Thailand on Thursday, 12 September 2019. > > We invite you to review and comment on the proposal on the mailing list > before the meeting. > > The comment period on the mailing list before an APNIC meeting is an > important part of the policy development process. We encourage you to > express your views on the proposal: > > - Do you support or oppose this proposal? > - Does this proposal solve a problem you are experiencing? If so, > tell the community about your situation. > - Do you see any disadvantages in this proposal? > - Is there anything in the proposal that is not clear? > - What changes could be made to this proposal to make it more > effective? > > Information about this proposal is available at: > http://www.apnic.net/policy/proposals/prop-132 > <http://www.apnic.net/policy/proposals/prop-132> > > Regards > > Sumon, Bertrand, Ching-Heng > APNIC Policy SIG Chairs > > > ---------------------------------------------------------------------- > > prop-132-v001: AS0 for Bogons > > ---------------------------------------------------------------------- > > Proposer: Aftab Siddiqui > [email protected] <mailto:[email protected]> > > > 1. Problem statement > -------------------- > 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. See [RFC3330] and [RFC1918]. > > As of now, there are 287 IPv4 bogons and 73 IPv6 bogons in the global > routing table. 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. Beside all these attempts the > issue > of Bogon Advertisement hasn't be resolved so far. > > > 2. Objective of policy change > ----------------------------- > The purpose of creating AS0 (zero) ROAs for unallocated address space by > APNIC > is to resolve the issue of Bogon announcement. When APNIC issues an AS0 > ROA for > unallocated address space in its bucket then it will be marked as > “Invalid” if > someone tries to advertise the same address space. > > 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 address space > in its bucket > (IPv4 and IPv6). Any resource holder can create AS0 (zero) ROAs for the > resources they > have under their account. > > A ROA is a positive attestation that a prefix holder has authorised an > AS to originate a > route for this prefix whereas, a 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 custodian. > > Only APNIC has the authority to create ROAs for address space not yet > allocated to the members > and only APNIC can issue AS0 (zero) ROAs. Once they ROA is issued and > APNIC wants to allocate > the address space to its member, simply they can revoke the ROA and > delegate the address space > to members. (this proposal doesn't formulate operational process). > > > 5. Advantages / Disadvantages > ----------------------------- > Advantages: > Those implementing ROV globally and discarding the invalids will be able > to discard bogons from > APNIC region automatically. > > Disadvantages: > 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 - https://tools.ietf.org/rfc/rfc6483.txt > <https://tools.ietf.org/rfc/rfc6483.txt> > RFC6491 - https://tools.ietf.org/rfc/rfc6491.txt > <https://tools.ietf.org/rfc/rfc6491.txt> > RFC7607 - https://tools.ietf.org/rfc/rfc7607.txt > <https://tools.ietf.org/rfc/rfc7607.txt> > * sig-policy: APNIC SIG on resource management policy > * > _______________________________________________ > sig-policy mailing list > [email protected] > https://mailman.apnic.net/mailman/listinfo/sig-policy
* sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list [email protected] https://mailman.apnic.net/mailman/listinfo/sig-policy
