I do not support this proposal. Intention is good but no one is really 
concerned nor can verify this in practice. I think the current policy text is 

Kind regards
Javed Khan

From: sig-policy-boun...@lists.apnic.net <sig-policy-boun...@lists.apnic.net> 
on behalf of Sumon Ahmed Sabir <sasa...@gmail.com>
Sent: Saturday, 10 August 2019 10:33 PM
To: Policy SIG <sig-pol...@apnic.net>
Subject: [sig-policy] prop-124-v006: Clarification on Sub-Assignments

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:

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

1. Problem Statement

Note that this proposal is ONLY relevant when end-users obtain direct
from APNIC, or when a LIR obtains, also from APNIC, and assignment for
use within its infrastructure. Consequently this is NOT relevant in case
of LIR

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
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
(/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

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
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
for exclusive use within the infrastructure they operate, as well as for

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

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.

*              sig-policy:  APNIC SIG on resource management policy           *
sig-policy mailing list

Reply via email to