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 <[email protected]>: > > 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 > [email protected] > > > 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 sub-assignments for ISP customers), and providing addressing space > to third > parties in data-centers (or similar cases), are not allowed. > > > 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 > [email protected] > https://mailman.apnic.net/mailman/listinfo/sig-policy * sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list [email protected] https://mailman.apnic.net/mailman/listinfo/sig-policy
