Info! Please note that this translation has been provided at best effort, for your convenience. The English page remains the official version.

Clarification on IPv6 Sub-Assignments v3

Print Friendly, PDF & Email

{tab Details}

Clarification on IPv6 Sub-Assignments

ID:

AFPUB-2018-V6-002-DRAFT03

Date Submitted:

11th November 2018

Author:

Jordi Palet Martinez

jordi.palet at theipv6company.com

The IPv6 Company

Version:

3.0

Obsoletes:

 

Amends:

CPM art 6.8

 {tab Proposal}

1.0 Summary of the problem being addressed by this proposal

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.

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.0 Summary of how this proposal addresses the problem

Section 2.6 (General Definitions/Assignment), explicitly prohibits such assignments, stating that “Assignments... are not to be sub-assigned to other parties”.

This proposal clarifies this situation in this regard and better define the concept, particularly considering new uses of IPv6 (RFC 8273), by means of new text at the end of whatever text is available at the IPv6 PI assignments policy.

It also clarifies that the usage of sub-assignments in ISPs, data centers and similar cases is not allowed.

 

3.0 Proposal

New Paragraph at the end of 6.8 of the CPM, as follows:

Current

Proposed

6.8 PI Assignments

(at the end of the section, precedent text unchanged by this proposal)

 

 

6.8 PI Assignments

(at the end of the section, precedent text unchanged by this proposal)

 

It is allowed to use the assigned addresses for:

a)     the assignment holder network

b)     third party devices operating within that infrastructure

c)      interconnections

It will be considered a sub-assignment and consequently it is not allowed, to use the assigned addresses for providing services to customers (such an ISP), data-center or similar cases.

 

 4.0 Revision History

Date

Details

20 March 2018

Version 1: AFPUB-2018-V6-002-DRAFT01

Initial Draft Posted to rpd

22 August 2018

Version 2: AFPUB-2018-V6-002-DRAFT02

  • Updated the problem statement
  • Proposed wording updated from v1 to v2 for more clarity.

11 November 2018

Version 3: AFPUB-2018-V6-002-DRAFT03

 

Added the following text to 6.8:

 

It is allowed to use the assigned addresses for:

a)     the assignment holder network

b)     third party devices operating within that infrastructure

c)      interconnections

 

It will be considered a sub-assignment and consequently it is not allowed, to use the assigned addresses for providing services to customers (such an ISP), data-center or similar cases.

 

 

5.0 References            

A similar proposal is being discussed in APNIC, LACNIC and RIPE.

 

{/tab}

Last Modified on -
Date and time in Mauritius -