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
