Hi all, If this proposal reaches consensus and endorsed by the APNIC EC, this is how we would implement the policy.
**Creation of AS0 (Zero) ROA - Based on the publicly available “delegated-apnic-extended-latest” stats file at https://ftp.apnic.net/stats/apnic/ - All resources (IPv4 and IPv6) flagged as “Available” and “Reserved” will be added to the AS0 ROA. - On average 15 records are updated in the “delegated-apnic-extended-latest" file daily. - AS0 ROA will be updated at the same time as resource (IPv4 and IPv6) delegation to exclude these prefixes. - Relying party will see the changes when the propagation of updated AS0 ROA is completed and this may take up to 24 hours. - As a reference, the default sync periods of some relying party validation tools are as follows: - RIPE validator v2: every hour - RIPE validator v3: every 10 minutes - Routinator: every hour - rcynic: every hour **Account closure - APNIC makes extensive effort to contact the Member - If all efforts failed, APNIC will decide to terminate and reclaim all resources delegated to that member. At the same time/day all whois objects for that account will be deleted. - “delegated-apnic-extended-latest” stats file is updated within 24hours to flag the reclaimed resources as “Reserved” - Reclaimed resource prefixes will be added to the AS0 ROA at the time of reclamation. - If the closed member created any ROAs these will be deleted at the time of reclamation. **Account reactivation - If the APNIC Member reactivates the account within 3 months from the account closure, APNIC will re-delegate the reclaimed resources and reinstates whois objects and ROAs. - “delegated-apnic-extended-latest” stats file is updated within 24hours to flag the re-delegated resources as “Allocated or Assigned” - At the time of reactivation, AS0 ROA will be updated to exclude the re-delegated prefixes **Clarifications requested: The way in which the ROAs appear in the RPKI needs to be considered. Currently, the hierarchy involves a TA (for 0/0, ::/0, etc.), an intermediate CA (same resource set), five further CAs (one for IANA and one for each other RIR), and then the member CAs (see diagram on slide 8 of https://conference.apnic.net/44/assets/files/APCS549/Transitioning-to-a-single-TA.pdf). Three possible options are: - have the intermediate CA issue an AS0 ROA; - have each of the IANA/RIR CAs issue an AS0 ROA; - construct a separate CA under each of the IANA/RIR CAs containing the relevant unallocated resources, and have each of those CAs issue an AS0 ROA. Does the community have any preference out of these three options? Regards Sunny _______________________________________________________________________ Srinivas (Sunny) Chendi Senior Advisor - Policy and Community Development Asia Pacific Network Information Centre (APNIC) | Tel: +61 7 3858 3100 PO Box 3646 South Brisbane, QLD 4101 Australia | Fax: +61 7 3858 3199 6 Cordelia Street, South Brisbane, QLD | http://www.apnic.net _______________________________________________________________________ On 27/08/2019 9:25 am, Srinivas (Sunny) Chendi wrote: > Hi Javed, > > Thanks for your email and for your participation in the policy > development process. > > We're consulting our experts to provide a response to your query soon. > Please allow us sometime. > > Regards > Sunny > > On 24/08/2019 12:28 am, Javed Khan wrote: >> For now, I'm neither for or against this proposal. I think the >> intention of the author is good but the implementation is not as easy >> as is explained in the proposal. QoS is very crucial for ISPs to >> sustain the fierce market competition and if APNIC fails to timely >> update the AS0 ROAs, this will effect the service delivery and/or >> network downtime. >> >> I request APNIC to provide a detailed review of this proposal from a >> service and legal perspective so the community can better understand >> the implementation, if this proposal reaches consensus. >> >> >> Kind regards >> Javed Khan >> MSCE and CCSP >> >> >> ------------------------------------------------------------------------ >> *From:* sig-policy-boun...@lists.apnic.net >> <sig-policy-boun...@lists.apnic.net> on behalf of David Farmer >> <far...@umn.edu> >> *Sent:* Friday, 23 August 2019 10:48 AM >> *To:* Aftab Siddiqui <aftab.siddi...@gmail.com> >> *Cc:* Sumon Ahmed Sabir <sasa...@gmail.com>; Policy SIG >> <sig-pol...@apnic.net> >> *Subject:* Re: [sig-policy] prop-132-v002: AS0 for Bogons >> >> >> On Thu, Aug 22, 2019 at 9:04 PM Aftab Siddiqui >> <aftab.siddi...@gmail.com <mailto:aftab.siddi...@gmail.com>> wrote: >> >> Hi David, >> >> >> On Fri, Aug 23, 2019 at 6:36 AM David Farmer <far...@umn.edu >> <mailto: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? >> >> >> I also had some concerns about revoked and/or reclaimed space and >> closed account due to non payment so I asked Secretariat in advance >> and here is the response. >> ======= >> APNIC membership account is classified as closed when its status is >> flagged as ‘closed’ in APNIC’s internal system. >> >> 30 days - payment period upon issuance of invoice, if no payment is >> received within this period member receives expiry notice and the >> account status becomes 'suspended' >> After 15 days – member receives email notification for closure >> giving them another 15 days to pay >> After 15 days – the status of the account becomes 'closed' and all >> delegated resources under the account are reclaimed >> >> All in all members have 60 days period to pay before the status of >> the account becomes ‘closed’. >> ======= >> >> As long as the account is suspended APNIC doesn't consider those >> resources as free/available/reclaimed and because they are not part >> of unallocated pool thats why no need to create AS0 ROAs for such >> resources. AS0 ROAs will be created once APNIC mark those resources >> available and remove them from their delegation record. Now, the >> second issue is if there is a ROA for them in the system. Because AS >> 0 ROA has a lower relative preference than any other ROA that has a >> routable AS then APNIC has to somehow delete the existing ROA from >> the system. Its easy if the member account is closed and all >> resources are reclaimed. But I leave this to APNIC to decide how >> they are going to make that happen. >> >> >> Currently, when the account is closed nothing actively makes the >> resources unusable, accept for if you were also changing providers >> during this timeframe, then when the new provider checks the resources >> they will be unregistered. But most providers don't recheck the >> registration of resources very often, if ever, other than at the time >> of setup of service. >> >> With this proposal at some point, the resource will effectively become >> unusable with nonpayment, when the AS0 ROA is created, and any ROAs >> are removed, I'm fine with this, but it should be called out as a >> consequence of the proposal, so no one can say they didn't realize >> that is a consequence of the proposal. >> >> This proposal changes the consequences for nonpayment, that should be >> made clear in the proposal one way or another. >> >> Also as Owen noted the RIRs frequently have a hold period after the >> account is closed, resource are usually held for some period after >> account closure and before they are reissued to a new user. >> >> 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; >> >> 1. Upon de-reregistration any existing ROAs are removed from >> RPKI >> 2. 30 days after de-registraion, AS0 ROAs are created except >> for non-payment fees >> 3. 90 days after de-registraion, AS0 ROAs are created in the >> case of non-payment fees >> >> Thanks. >> >> >> Thanks for these suggestions but do you think the existing waiting >> period as outlined above in APNIC's response is good enough to mark >> them as free/unallocated? or you think additional cooling-off window >> should be added after the account is closed? How about 30 days after >> de-registration whether it was closed due to non-payment or >> otherwise. >> >> >> They were just suggestions, but I will note that you only discussed >> the timing for nonpayment, resources can be returned voluntarily or >> they can be revoked for cause, this is rare but it does happen and the >> timing assoicated with these instances should be understood as well. >> >> Also, I was suggesting the AS0 ROAs should not created immediately on >> account closure but some period of time after that, >> >> Right now there seems to be two phases, suspension and account >> closure, I'm proposing a third phase resource deactivation, the >> creation of the AS0 ROAs. I suppose account closure and resource >> deactivation can occur simultaneously, I think they should be separate >> as an escalating series of events. >> 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 >> >> 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 >> RFC6491 - https://tools.ietf.org/rfc/rfc6491.txt >> RFC7607 - 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 >> >> >> >> -- =============================================== >> 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 <mailto:sig-policy@lists.apnic.net> >> 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
