[sig-policy] prop-132 new version email draft (003)
Dear SIG members A new version of the proposal "prop-132: RPKI ROAs for unallocated and unassigned APNIC address space (was: 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-v003: RPKI ROAs for unallocated and unassigned APNIC address space (was: AS0 for Bogons) - Proposer: Aftab Siddiqui aftab.siddi...@gmail.com 1. Problem statement Address space managed by APNIC which has is either "Unallocated" or "Unassigned" is considered "Bogon address space". 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. As of now, there are XXX IPv4 and YYY IPv6 routes in the global Internet routing table which cover address space ma naged by APNIC, but which is not allocated or assigned by APNIC. 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. Despite these attempts, the issue of unauthorized advertisements of APNIC's address space hasn't be resolved so far. 2. Objective of policy change - The purpose of creating RPKI ROAs with Origin AS 0 for APNIC's unallocated and unassigned address space is to restrict the propagation of BGP announcements covering such bogon space. When APNIC issues a ROA with AS 0 for unallocated address space under APNIC's administration, BGP announcements covering this space will be marked as Invalid by networks doing RPKI based BGP Origin Validation using APNIC's TAL. 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 and unassigned 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 RPKI ROA is a positive attestation that a prefix holder has authorised an AS to originate a route for this prefix whereas, a RPKI 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 RPKI ROAs for address space not yet allocated to the members and only APNIC can issue AS0 (zero) RPKI ROAs. Once they RPKI ROA is issued and APNIC wants to allocate the address space to its member, simply they can revoke the RPKI ROA and delegate the address space to members. (this proposal doesn't formulate operational process). 5. Advantages / Disadvantages - Advantages: Network operators who implement RPKI based Origin Validation and discard BGP announcements with RPKI state "invalid", will automatically discard BGP announcements covering unallocated & unassigned APNIC address space. Ensuring unallocated or unassigned address space is not usable by unauthorized parties makes more address space available for those who qualify to receive an allocation or assignment from APNIC. 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. APNIC Member failing to pay fees on time as per membership agreement may loose the right to use the allocated resources after membership termination and those resources may end up in
Re: [sig-policy] prop-132-v001 AS0 for Bogons
Dear Colleagues, I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team. I would like to share a feedback in our community for prop-132, based on a meeting we organized on 21th Aug to discuss these proposals. Please note that these discussion is based on the first Proposal, prop-132-0001. Many participants basically support this proposal. But If an incorrect ROA is created due to a miss-operation or unexpected trouble, not only the quality of the network will be degraded, but it may adversely affect the deployment of RPKI in this community. We hope careful deployment such as having a sufficient test period if this proposal reach consensus. Best Regards, Satoru Tsurumaki JPOPF-ST 2019年8月9日(金) 19:02 Sumon Ahmed Sabir : > > > 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 > > Regards > > Sumon, Bertrand, Ching-Heng > APNIC Policy SIG Chairs > > > -- > > prop-132-v001: AS0 for Bogons > > -- > > Proposer: Aftab Siddiqui >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
Re: [sig-policy] prop-131-v001: Editorial changes in IPv6 Policy
Dear Colleagues, I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team. I would like to share a feedback in our community for prop-131, based on a meeting we organized on 21th Aug to discuss these proposals. Many participants expressed a opposing for the proposal with reasons that the policy document should not refer the document(RIPE BCOP) which was made and managed by out of our community and if the document is unintentionally modified or obsolete, we cannot control it. Best Regards, Satoru Tsurumaki JPOPF-ST 2019年8月9日(金) 18:59 Sumon Ahmed Sabir : > > > Dear SIG members, > > The proposal "prop-131-v001: Editorial changes in IPv6 Policy" 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-131 > > Regards > > Sumon, Bertrand, Ching-Heng > APNIC Policy SIG Chairs > > > -- > > prop-131-v001: Editorial changes in IPv6 Policy > > -- > > Proposer: Jordi Palet Martínez >jordi.pa...@theipv6company.com > > > 1. Problem Statement > > > This proposal suggests multiple (mainly) editorial changes in the IPv6 > Policy. > The intent is to remove non-necessary text, and simplify the policy. > > Section 5.2.4.2. is reworded to mention a RIPE BCOP, and 5.2.4.4. is > removed, > as it is something obvious that operators need to assign some space for > different > parts of their own infrastructure. > > Section 5.2.4.3. explicitly states that it was drafted at a time when > there was no > experience with IPv6 deployment, which is this is longer the case, it > does not make > sense to have NIR/RIR to evaluate each instance where an LIR has an End > User whose > end site(s) requires a shorter prefix than a /48. > > Finally, section 10.1.4.1. is reworded, taking advantage of some of the > editorial > changes in the precedent sections, so to avoid duplicating text. > > > > 2. Objective of policy change > - > > Fulfil the above indicated edits. > > > 3. Situation in other regions > - > > A similar proposal has been submitted to RIPE. > > > 4. Proposed policy solution > --- > > Current Text > 5.2.4.2. Assignment address space size > > ... > > End-users are assigned an end site assignment from their LIR or ISP. The > exact size of > the assignment is a local decision for the LIR or ISP to make, using a > minimum value of > a /64 (when only one subnet is anticipated for the end site) up to the > normal maximum of > /48, except in cases of extra large end sites where a larger assignment > can be justified. > > ... > > > New Text > 5.2.4.2. Assignment address space size > > ... > > End Users are assigned an end site assignment from their LIR or ISP. The > size of the > assignment is a local decision for the LIR or ISP to make, using a value > of "n" x /64. > BCOP RIPE690 Section 4.2, provides guidelines about this. > > ... > > == > > Current Text > 5.2.4.3. Assignment of multiple /48s to a single end site > > When a single end site requires an additional /48 address block, it must > request the > assignment with documentation or materials that justify the request. > Requests for multiple > or additional /48s will be processed and reviewed (i.e., evaluation of > justification) at > the RIR/NIR level. > > Note: There is no experience at the present time with the assignment of > multiple /48s to > the same end site. Having the RIR review all such assignments is > intended to be a temporary > measure until some experience has been gained and some common policies > can be developed. > In addition, additional work at defining policies in this space will > likely be carried out > in the near future. > > > New Text > 5.2.4.3. Assignment of multiple /48s to a single end site > > Assignment larger than /48 (shorter prefix) or additional assignments > exceeding a total of > /48 must be made based on address usage, or because different routing > requirements exist > for additional assignments. > >
Re: [sig-policy] Policy Proposal: prop-130-v001: Modification of transfer policies
Dear Colleagues, I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team. I would like to share a feedback in our community for prop-130, based on a meeting we organized on 21th Aug to discuss these proposals. Many participants expressed a neutral for the proposal with reasons that they don't imagine the reason why we need to change the policy. Best Regards, Satoru Tsurumaki JPOPF-ST 2019年3月14日(木) 21:59 Sumon Ahmed Sabir : > > > Dear SIG members, > > The proposal "prop-130-v001: Modification of transfer policies" > 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-130 > > Regards > > Sumon, Bertrand, Ching-Heng > APNIC Policy SIG Chairs > * 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
Re: [sig-policy] prop-124-v006: Clarification on Sub-Assignments
Dear Colleagues, I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team. I would like to share a feedback in our community for prop-124,based on a meeting we organized on 21th Aug to discuss these proposals. Many participants expressed a neutral for the proposal with reasons that the problem in the current policy is something vague. Best Regards, Satoru Tsurumaki JPOPF-ST 2019年8月10日(土) 23:33 Sumon Ahmed Sabir : > > Dear SIG members > > A new version of the proposal "prop-124: Clarification on Sub-Assignments" > 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. > > Information about earlier versions is available from: > https://www.apnic.net/community/policy/proposals/prop-124 > > 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-124-v006: Clarification on Sub-Assignments > > -- > > Proposer: Jordi Palet Martínez >jordi.pa...@theipv6company.com > > > 1. Problem Statement > > > Note that this proposal is ONLY relevant when end-users obtain direct > assignments > from APNIC, or when a LIR obtains, also from APNIC, and assignment for > exclusive > use within its infrastructure. Consequently this is NOT relevant in case > of LIR > allocations. > > When the policy was drafted, the concept of assignments/sub-assignments > did not > consider a practice very common in IPv4 which is replicated and even > amplified > in IPv6: the use of IP addresses for point-to-point links or VPNs. > > In IPv4, typically, this is not a problem if NAT is being used, because > the assigned > addresses are only for the WAN link, which is part of the infrastructure > or interconnection. > > In the case of IPv6, instead of unique addresses, the use of unique > prefixes > (/64) is increasingly common. > > Likewise, the policy failed to consider the use of IP addresses in > hotspots hotspots > (when is not an ISP, for example, associations or community networks), > or the use of > IP addresses by guests or employees in Bring Your Own Device (BYOD) and > many other > similar cases. > > One more case is when an end-user contracts a third-party to do some > services in their > own network and they need to deploy their own devices, even servers, > network equipment, > etc. For example, security surveillance services may require that the > contractor provides > their own cameras, recording system, even their own firewall and/or > router for a dedicated > VPN, etc. Of course, in many cases, this surveillance system may need to > use the addressing > space of the end-user. > > Finally, the IETF has recently approved the use of a unique /64 prefix > per interface/host > (RFC8273) instead of a unique address. This, for example, allows users > to connect to a hotspot, > receive a /64 such that they are “isolated” from other users (for > reasons of security, > regulatory requirements, etc.) and they can also use multiple virtual > machines on their > devices with a unique address for each one (within the same /64). > > > 2. Objective of policy change > - > > Section 2.2.3. (Definitions/Assigned Address Space), explicitly > prohibits such assignments, > stating that “Assigned ... may not be sub-assigned”. > > It also clarifies that the usage of sub-assignments in ISPs, data > centers and similar cases > is not allowed, according to the existing practices of APNIC. > > > 3. Situation in other regions > - > > This situation, has already been corrected in AFRINIC, ARIN, LACNIC and > RIPE. > > > 4. Proposed policy solution > --- > > Current Text > 2.2.3. Assigned address space > Assigned address space is address space that is delegated to an LIR, or > end-user, > for specific use within the Internet infrastructure they operate. > Assignments must > only be made for specific, documented purposes and may not be sub-assigned. > > > New text: > 2.2.3. Assigned address space > Assigned address space is address space that is delegated to an LIR, or > end-user, > for exclusive use within the infrastructure they operate, as well as for > interconnection > purposes. > > The assigned address space must only be used by the original recipient > of the assignment, > as well as for third party devices provided they are operating within > said infrastructure. > > Therefore, sub-assignments to third parties outside said infrastructure > (for example > using
Re: [sig-policy] Version 4 of prop-126 PDP Update
Dear Colleagues, I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team. I would like to share a feedback in our community for prop-126, based on a meeting we organized on 21th Aug to discuss these proposals. Many participants expressed a supporting for the proposal with reasons that discussions in the mailing list will be reflected more than ever, also with the reason that expiring policy of the proposal at Step 4 sound good both author and community. And a few question were expressed as below: - In Step2, it seems difficult to understand the process. Which is correct? 1. Consensus is determined... Firstly SIG mailing list/other electronic means/the SIG session and then Member Meeting 2. Consensus is determined... Firstly SIG mailing list/other electronic means and then SIG Session Afterward Member Meeting - What is "other electronic means" ? Is it CONFER? If it is CONFER, I am concerned that CONFER does not know the exact number of people who voted. Best Regards, Satoru Tsurumaki JPOPF-ST 2019年8月9日(金) 3:14 Sumon Ahmed Sabir : > > > Dear SIG members > > A new version of the proposal "prop-126: PDP Update" 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. > > Information about earlier versions is available from: > https://www.apnic.net/community/policy/proposals/prop-126/ > > 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-126-v004: PDP Update > > -- > > Proposer: Jordi Palet Martínez >jordi.pa...@theipv6company.com > > > 1. Problem Statement > > > With its requirement of face-to-face participation at the OPM, the current > PDP might – at least partially – be the cause of the low levels of > community > participation in the process by using the policy mailing list. > > This proposal would allow an increased participation, by explicitly > considering > the comments in the list for the consensus determination. So, > consensus would > be determined balancing the mailing list and the forum, and would therefore > increase community participation. > > Even if this is actually done by the chairs, it is not part of the > actual PDP, > and thus constitutes a very clear and explicit violation of the PDP and > the risk > is that anyone from the community could appeal any decision based on that. > > Finally, it completes the PDP by adding a simple mechanism for solving > disagreements > during an appeals phase and an improved definition of ‘consensus’, as > well as a > complete definition of the “consensus” and “last-call”. > > > 2. Objective of policy change > - > > To allow that consensus is determined formally looking at the opinions > of community > members that are not able to travel to the meetings and facilitating a > simple method > for appeals. > > > 3. Situation in other regions > - > > The PDP is different in the different RIRs. This proposal is similar to > the RIPE PDP, > possibly the region with the broadest participation in its policy > proposal discussions, > although there are certain differences such as the mandatory use of the > mailing list and > the meeting, which is more similar to the PDP at ARIN (another region > with broad community > participation). LACNIC has recently adopted a similar policy proposal > with the same aims. > > > 4. Proposed policy solution > --- > > Current Text > Step 2: Consensus at the OPM > Consensus is defined as “general agreement” as observed by the Chair of > the meeting. > Consensus must be reached first at the SIG session and afterwards at the > Member Meeting > for the process to continue. If there is no consensus on a proposal at > either of these > forums, the SIG (either on the mailing list or at a future OPM) will > discuss whether to > amend the proposal or to withdraw it. > > New Text > Step 2: Consensus Determination > Consensus is defined as “rough consensus” as observed by the Chairs. > > Consensus is determined first considering the SIG mailing list, other > electronic means, > and the SIG session, and afterwards at the Member Meeting. > > If there is no consensus on a proposal, the authors can decide to > withdraw it. > > Otherwise, the proposal will expire in six months, unless a new version > is provided, > restarting the discussions with the community. > >
