[sig-policy] prop-124-version 5: Clarification on IPv6 Sub-Assignments

  • To: "Policy SIG" <sig-policy@apnic.net>
  • Subject: [sig-policy] prop-124-version 5: Clarification on IPv6 Sub-Assignments
  • From: "Bertrand Cherrier" <b.cherrier@micrologic.nc>
  • Date: Thu, 10 Jan 2019 15:28:31 +1100
  • Delivered-to: sig-policy@clove.apnic.net
  • Dkim-signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=micrologic.nc; s=mail; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=gvLZXHNxGERc8yU7JvB5DsR2BmO0zR6XlyXIX5pPNBc=; b=OCCuDVC7oBz3M0x8queEEbkSIij4akBSMTwdnNO0DID5B96CCB9L8o1XK2QYzZxmfxqzQDBocrW59nJBlZOJ4mxVCIJsOeyBPLFGhpeWMm6BVRo8YcWdKr65jcBp3S3JJbB5ddvNgDnXhqCugiXoBwJvv4dKoIkIuEe6UFwc92k=;
  • 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,

      We wish you all the best for this new year !

      A new version of the proposal "prop-124: Clarification on IPv6
      has been sent to the Policy SIG for review.

      Information about earlier versions is available from:


      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

      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
      within the original holder infrastructure.

      Sub-assignments are not allowed outside that infrastructure (for example
      sub-assignments for ISP customers), neither for providing addressing
      space to
      third parties in data-centers (or similar cases).

      5. Advantages / Disadvantages

      Fulfilling the objective above indicated and making sure to match the real
      situation in the market.

      None foreseen.

      6. Impact on resource holders


      7. References

      Links to RIPE policy amended and new policy proposal submitted.