---------------------------------------------------------------------- prop-124-v006: Clarification on Sub-Assignments ---------------------------------------------------------------------- Proposer: Jordi Palet Martínez jordi.palet@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 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.