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-bounces@lists.apnic.net
>> <sig-policy-bounces@lists.apnic.net> on behalf of David Farmer
>> <farmer@umn.edu>
>> *Sent:* Friday, 23 August 2019 10:48 AM
>> *To:* Aftab Siddiqui <aftab.siddiqui@gmail.com>
>> *Cc:* Sumon Ahmed Sabir <sasabir@gmail.com>; Policy SIG
>> <sig-policy@apnic.net>
>> *Subject:* Re: [sig-policy] prop-132-v002: AS0 for Bogons
>>
>>
>> On Thu, Aug 22, 2019 at 9:04 PM Aftab Siddiqui
>> <aftab.siddiqui@gmail.com <mailto:aftab.siddiqui@gmail.com>> wrote:
>>
>> Hi David,
>>
>>
>> On Fri, Aug 23, 2019 at 6:36 AM David Farmer <farmer@umn.edu
>> <mailto:farmer@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
>> <sasabir@gmail.com <mailto:sasabir@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.siddiqui@gmail.com <mailto:aftab.siddiqui@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:farmer@umn.edu <mailto:Email%3Afarmer@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:farmer@umn.edu <mailto:Email%3Afarmer@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