Hi Abdul,
Responding to you and Owen, as it seems you have the same feeling/questions. There is no text in the existing policy that I’m suggesting to amend, that say that the sub-assignment needs to be registered. There is no text that excludes the point-to-point links from that policy text (in fact Owen said “generally”). There is no text that indicates if it is ok to use and end-user assignment for a Data Center and then sub-allocate to hosting or housing customers, even if you don’t register them at the RIR level, however, when I asked all the RIRs about that, all them responded that a DC for services to third parties is considered a case for LIR space, not end-user one. Last, but not least, this issue started in RIPE, because some community networks offering free hotspot services, couldn’t get from the RIPE NCC that end-user addressing space, so a policy modification was required. Then, I submitted a policy proposal to all the other 4 RIRs, to clarify the same question, because all that text was basically the same in all the regions, and as one of the ARIN AC members (Chris Woodfield) already indicated in this list on his email from 11th January), “ARIN recently adopted a proposal to solve the same problem statement”. Regards, Jordi De: <sig-policy-boun...@lists.apnic.net> en nombre de "Md. Abdul Awal" <awal....@gmail.com> Fecha: miércoles, 27 de febrero de 2019, 1:37 Para: <sig-policy@lists.apnic.net> Asunto: Re: [sig-policy] prop-124-version 5: Clarification on IPv6 Sub-Assignments I agree with Owen and would like to express opposition to this proposal. I believe the term "sub-assignment" has the indication of making official sub distribution of addresses by and LIR/ISP to their client organizations. The concerns addressed in this proposal seem to be covered already within the current texts in the quoted section of current policy. Or, at least not explicitly supports any of the situation mentioned in the proposal. BR//Awal On 22/2/19 4:09 PM, Owen DeLong wrote: I express opposition to this policy change. There seems to me a misunderstanding of the term sub assignments in the proposal. A subassignment is an issuance of a portion of your prefix to an external third party recorded at the RIR level or provided in a public database (e.g. whois, rwhois, or RDAP). Point to point prefixes are generally exempt from being reported to the registry. In the case of a guest WiFi or VPN, again, these are not generally considered to be external subassignments subject to reporting. The intent of the policy as written as I understand it (and staff, please clarify if APNIC is applying different interpretation) is to cover situations where an LIR (whether service provider or otherwise) is making recorded delegations of smaller blocks of address space to external entities (e.g. when an ISP assigns a /48 to a customer end site). It is not intended to and does not (to the best of my knowledge) preclude any of the use cases you have mentioned. Owen On Feb 21, 2019, at 21:46 , JORDI PALET MARTINEZ <jordi.pa...@consulintel.es> wrote: Dear Satoru, all, First of all, thanks a lot for your inputs! Let me try to clarify this. The text of the problem statement has been the same (maybe minor variations) across the 4 previous versions, so it is difficult to understand what is not clear now, which can have been addressed before. In any case, what it matters in a policy proposal, is the policy text and the objective of the change. What happens with current policy is that if you’re an enterprise with assigned addressing space, you can only use it for your own infrastructure and within it. If you want to have a “guest” WiFi (visitors in the company, students in a University), or you need to provide it via VPN, or point-to-point links, it is not allowed. The problem statement just provides more examples and cases, but everything boils down to the same. I don’t think that was the intended purpose of the original policy, but that text has been carried out from IPv4 policies, and in most of the cases, there you don’t have the same problem because you’re providing to the visitors or students private addressing space behind a NAT. Let me know please, if this is clearer as a “short” for the problem statement and objective of the policy change. Regards, Jordi De: <sig-policy-boun...@lists.apnic.net> en nombre de Satoru Tsurumaki <satoru.tsurum...@g.softbank.co.jp> Fecha: viernes, 22 de febrero de 2019, 12:29 Para: Policy SIG <sig-pol...@apnic.net> Asunto: Re: [sig-policy] prop-124-version 5: Clarification on IPv6 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 12th Feb to discuss these proposals. Many participants expressed a neutral for the proposal with reasons that the problem in the current policy is something vague. And a few opposing comments were expressed with same reason as above. Best Regards, Satoru Tsurumaki JPOPF-ST 2019年1月10日(木) 13:28 Bertrand Cherrier <b.cherr...@micrologic.nc>: Dear SIG members, We wish you all the best for this new year ! A new version of the proposal "prop-124: Clarification on IPv6 Sub-Assignments" has been sent to the Policy SIG for review. 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-v005: Clarification on IPv6 Sub-Assignments Proposer: Jordi Palet Martínez jordi.pa...@theipv6company.com 1. Problem Statement 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 because the usage of NAT. 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”. This proposal clarifies this situation in this regard and better define the concept, particularly considering new uses of IPv6 (RFC8273), by means of new text. It also clarifies that the usage of sub-assignments in ISPs, data centers and similar cases is not allowed. 3. Situation in other regions This situation, has already been corrected in RIPE, and the policy was updated in a similar way, even if right now there is a small discrepancy between the policy text that reached consensus and the RIPE NCC Impact Analysis. A new policy proposal has been submitted to amend that, and the text is the same as presented by this proposal at APNIC. Same text has also been submitted to AfriNIC (already reached consensus), LACNIC and ARIN. 4. Proposed policy solution Add a new paragraph after the existing one in 2.2.3. Actual 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 address space assignment is only for use by the original holder of said assignment, as well as for third party devices, as long as they are operating within the original holder infrastructure. Sub-assignments are not allowed outside that infrastructure (for example using sub-assignments for ISP customers), neither for providing addressing space to third parties in data-centers (or similar cases). 5. Advantages / Disadvantages Advantages: Fulfilling the objective above indicated and making sure to match the real situation in the market. Disadvantages: None foreseen. 6. Impact on resource holders None. 7. References Links to RIPE policy amended and new policy proposal submitted. * 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 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. * 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 * 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 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
* 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
