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 <sasa...@gmail.com> 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
>            aftab.siddi...@gmail.com <mailto:aftab.siddi...@gmail.com>
> 
> 
> 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
> sig-policy@lists.apnic.net
> https://mailman.apnic.net/mailman/listinfo/sig-policy

*              sig-policy:  APNIC SIG on resource management policy           *
_______________________________________________
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

Reply via email to