Presentation by Jordi Palet at APRICOT 2019 on Wednesday, 27 February 2019.

1. Clarification on IPv6
Sub-Assignments
Prop-124 v005
APNIC47 – Daejeon – South Korea
Jordi Palet
(jordi.palet@theipv6company.com)
1

2. Problem Statement (1)
• 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 (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. 2

3. Problem Statement (2)
• 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).
3

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

5. Situation in Other Regions
•This situation, has already been corrected in RIPE, and
the policy was updated in a similar way.
•Similar text has also been submitted to AfriNIC, LACNIC
and ARIN.
•Already reached consensus in ARIN (adopted already)
and AfriNIC.
5

6. Proposed Policy Solution
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 operating within the
original holder infrastructure.
Sub-assignments are not allowed outside that
infrastructure (for example using sub-assignments for ISP
customers), neither for providing addressing space to
third parties in data-centers (or similar cases).
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.

7. Advantages of the Proposal
•Fulfilling the objective above indicated and making
sure to match the real situation in the market.
7

8. Disadvantages of the Proposal
•None foreseen.
8

9. Impact on Resource Holders
•None.
9