[sig-policy] prop-124-v006: Clarification on Sub-Assignments

  • To: Policy SIG <sig-policy@apnic.net>
  • Subject: [sig-policy] prop-124-v006: Clarification on Sub-Assignments
  • From: Sumon Ahmed Sabir <sasabir@gmail.com>
  • Date: Sat, 10 Aug 2019 20:33:08 +0600
  • Delivered-to: sig-policy@clove.apnic.net
  • Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Wf3xNXReBKBtl8N0EnJOG9ZOEGgGLQkU9gqb7xktylU=; b=lshuSKfk7leZZIJHJPNQM9+mDlEfGu4ubV5zEz4VNqm+TSf1c8wexeG4ggZQS8bBuP xI6wsE1UenE8DL7ZNzJzD8XZOuk0ypYSSay/RoNceiI8A7BlLIFUjLW0QKiPs4l4GCjG SdXFiUu6A7ZR/sUgvYjAn2DS1YGaz4cDWOj0sEOeMbT2dyGhinRyhmi7/x89SwEvUrH3 VeJQ1IxzeHX4ovnudUblFpPFhYJUCzHpGCCgMk4TN+1ev615/4w3xNP7u1YK1nZAbUfK FdBt+Cs1lVYMp1IMdO0RTUfG4tYzd9OEavyh+g5p7BVZI8i67sgCbvU0xuQmZWCN+jhP R2Vg==
  • List-archive: <http://mailman.apnic.net/mailing-lists/sig-policy/>
  • List-help: <mailto:sig-policy-request@lists.apnic.net?subject=help>
  • List-id: APNIC SIG on resource management policy <sig-policy.lists.apnic.net>
  • List-post: <mailto:sig-policy@lists.apnic.net>
  • List-subscribe: <https://mailman.apnic.net/mailman/listinfo/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=subscribe>
  • List-unsubscribe: <https://mailman.apnic.net/mailman/options/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=unsubscribe>

    • 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.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.