Most, if not all RIRs have a process for address recycling with appropriate 
hold-down times and grace periods for the resource holder to act to preserve 
their claim on the resources.

It seems to me that lining this up with those procedures can be left as an 
operational manner at the discretion of staff, but I wouldn’t be opposed to 
specific minimums being elaborated in policy if people feel that is needed.

Staff should always be given the flexibility to accommodate entities staff 
believes to be acting in good faith, IMHO and the unintended consequences of 
any hard maximum time limits in policy could, be dire.

Owen


> On Aug 22, 2019, at 13:36 , David Farmer <far...@umn.edu> wrote:
> 
> The problem statement says;
> 
> 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)...
> 
> So that raises a question, what about resources that are deregisterd because 
> they are returned, revoked, or otherwise reclaimed, for any of a myriad of 
> reasons, including non-payment of fees? Do they become Bogons with AS0 ROAs 
> the moment they are deregistered? Later, if so when? What if there is a ROA 
> for them in the system? Are the ROAs removed, if so when? 
> 
> Personally I think they should be deregistered for some amount of time before 
> the becoming Bogons and have an AS0 ROA created them, also for the AS0 ROA to 
> be effective any ROAs for these deregistered resources need to be removed as 
> well.
> 
> I would propose something like the following;
> Upon de-reregistration any existing ROAs are removed from RPKI
> 30 days after de-registraion, AS0 ROAs are created except for non-payment fees
> 90 days after de-registraion, AS0 ROAs are created in the case of non-payment 
> fees
> Thanks.
> 
> On Thu, Aug 22, 2019 at 12:52 AM Sumon Ahmed Sabir <sasa...@gmail.com 
> <mailto:sasa...@gmail.com>> wrote:
> Dear SIG members
> 
> 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:
> http://www.apnic.net/policy/proposals/prop-132 
> <http://www.apnic.net/policy/proposals/prop-132>
> 
> You are encouraged to express your views on the proposal:
> 
>   - Do you support or oppose the proposal?
>   - Is there anything in the proposal that is not clear?
>   - What changes could be made to this proposal to make it more effective?
> 
> Please find the text of the proposal below.
> 
> Kind Regards,
> 
> Sumon, Bertrand, Ching-Heng
> APNIC Policy SIG Chairs
> 
> 
> ----------------------------------------------------------------------
> 
> prop-132-v002: 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 under APNIC’s administration 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 
> (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 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 <mailto:sig-policy@lists.apnic.net>
> https://mailman.apnic.net/mailman/listinfo/sig-policy 
> <https://mailman.apnic.net/mailman/listinfo/sig-policy>
> 
> -- 
> ===============================================
> David Farmer               Email:far...@umn.edu 
> <mailto:email%3afar...@umn.edu>
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota   
> 2218 University Ave SE        Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
> *              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