Review and correction of errors in the IPv6 policy

Original Language Español Date Published 27/02/2018 Last Modified 16/02/2018
Last Call for Comments Period 01/05/2018 - 31/05/2018 Date Ratified Does not apply Implementation Date 26/06/2018
Status Implemented Download TXT PDF XML DOCX
See other versions 1.0 (compare)

Authors

Name: Jordi Palet Martinez
Email: jordi.palet@consulintel.es
Organization: The IPv6 Company

General opinion

Proposal Data

Policy Type: LACNIC
Id: LAC-2018-4
Last version: 1
Presentations:

Summary

In recent years, different policy proposals have modified different parts of the policy for IPv6 address allocation and assignment, and these changes have led to several inconsistencies in the text.

In addition to ironing out such inconsistencies and even errors in references, this proposal updates an important reference to a very recent document to make it easier to understand how LIRs can assign IPv6 addresses to their users.

Rationale

This update will avoid misunderstandings and can be particularly helpful in solving one of the most serious problems in the region: the fact that a single /64 is assigned to end users, which is not correct in the case of IPv6.

The concept of “utilization” is clarified so it will have a neutral reading, regardless of the size of the prefix each ISP decides to assign.

The reference to the "HD-Ratio” appendix is also corrected.

Text

Current text:
4.2.1.
Unlike IPv4, IPv6 is generally assigned to end sites in fixed amounts.
The actual utilization of addresses within each assignment will be quite low when compared to IPv4 assignments.
In IPv6, "utilization" is only measured in terms of the bits to the left of the /56 boundary.
In other words, utilization refers to the assignment of /56s to end sites, and not to the number of addresses assigned within individual /56s at those end sites.
Throughout this chapter, the term utilization refers to the assignment of /56s to end sites, not to the number of addresses assigned in individual /56s at those end sites.
4.2.2.
HD Ratio ... where, in the case of this document, the objects are IPv6 site addresses (/48s) assigned from an IPv6 prefix of a given size (see Appendix 10.2).
4.5.3.1.
Assignments are to be made in accordance with the needs specified by the ISP's users as well as existing recommendations [RFC 6177], the most important of which are summarized below:
End users or end sites should be assigned enough addresses to meet their current and planned needs.
End users or end sites should not be assigned less than a /64.
The exact size of the assignment is an operational decision for the LIR or ISP to make.
RFC 6177 recommends assigning end users/sites more than a /64, but does not recommend adopting the plan to assign all end users/sites a /48 by default.
One recommendation would be to assign between a /48 and a /56.
RIRs/NIRs are not concerned with the prefix size assigned by an LIR/ISP.
Accordingly, RIRs/NIRs will not request detailed information on IPv6 user networks as they did in IPv4, except for the cases described in Section 4.5.2 and for the purpose of measuring utilization as defined in this chapter.

New Text

4.2.1.
Unlike IPv4, IPv6 is generally assigned to end sites in fixed amounts.
The actual utilization of addresses within each assignment will be quite low when compared to IPv4 assignments.
In IPv6, "utilization" is only measured in terms of the number of prefixes assigned to end users, not their size or the number of addresses actually used in those prefixes. This is how it should be understood throughout this document.
4.2.2.
HD Ratio ... where, in the case of this document, the objects are IPv6 site addresses (/48s) assigned from an IPv6 prefix of a given size (see Appendix 12.2).
4.5.3.1.
Assignment of address space. Assignments are to be made in accordance with the need specified by the ISP's user as well as with existing recommendations [RIPE-690, https://www.ripe.net/publications/docs/ripe-690], highlights of which are summarized below:
* End sites or users must be assigned a prefix that is a multiple of "n" /64’s which must be enough to meet their current and planned needs, considering existing protocols and future possibilities and thus avoiding possible renumbering scenarios.
* The size of the prefix to be assigned is an operational decision of the LIR/ISP, although the selection of /48s is recommended for simpler and more functional infrastructure for all the endpoints of the network.
* Persistent prefix assignments are recommended to avoid undesired failures.
* Using a /64 prefix for point-to-point with GUAs is recommended.
The size of LIRs/ISPs assignments does not concern RIRs/NIRs.
Accordingly, RIRs/NIRs will not request detailed information on IPv6 user networks as they did in IPv4, except for the cases described in Section 4.5.2 and for the purpose of measuring utilization as defined in this chapter.

Additional Information

This proposal does not imply any changes in how the policy currently in force is applied. Instead, the proposed changes are simply clarifications or involve correcting errors and updating references to avoid potential misinterpretations.

Timetable

Immediate implementation

References

RIPE-690, https://www.ripe.net/publications/docs/ripe-690

Public Comments by LACNIC Staff

LACNIC STAFF´S IMPACT ANALYSIS - Proposal LAC-2018-4 - versión 1

LACNIC Staff's Interpretation of the Proposal
----------------------------------------------------
Applicability
--------- ---
- Applicability of section 4.2.1. Utilization: 

This proposal modifies the definition of ‘utilization', which is used when evaluating a request for IPv6 addresses.

- Applicability of section 4.2.2. HD Ratio:
Corrects the number of the appendix where HD Ratio is defined.

- Applicability of section 4.5.3.1. Address space assignment:
This section is a recommendation to ISPs making assignments to end users.

Modifications to the current text

--------------------------------
The Policy Manual would be modified as follows:

* Modification of section 4.2.1. Utilization.

Unlike IPv4, IPv6 is generally assigned to end sites in fixed amounts.
The actual utilization of addresses within each assignment will be quite low when compared to IPv4 assignments.

In IPv6, "utilization" is only measured in terms of the number of prefixes assigned to end users, not their size or the number of addresses actually used in those prefixes. This is how it should be understood throughout this document.

* Modification of section 4.2.2. HD Ratio
... where, in the case of this document, the objects are IPv6 site addresses (/48s) assigned from an IPv6 prefix of a given size (see Appendix 12.2).
4.5.3.1.

* Modification of section 4.5.3.1. Assignment of address space.
Assignments are to be made in accordance with the need specified by the ISP's user as well as with existing recommendations [RIPE-690, https://www.ripe.net/publications/docs/ripe-690], highlights of which are summarized below:
-End sites or users must be assigned a prefix that is a multiple of "n" /64’s which must be enough to meet their current and planned needs, considering existing protocols and future possibilities and thus avoiding possible renumbering scenarios.
-The size of the prefix to be assigned is an operational decision of the LIR/ISP, although the selection of /48s is recommended for simpler and more functional infrastructure for all the endpoints of the network.
-Persistent prefix assignments are recommended to avoid undesired failures.
-Using a /64 prefix for point-to-point with GUAs is recommended.

The size of LIRs/ISPs assignments does not concern RIRs/NIRs.
Accordingly, RIRs/NIRs will not request detailed information on IPv6 user networks as they did in IPv4, except for the cases described in Section 4.5.2 and for the purpose of measuring utilization as defined in this chapter.

LACNIC Staff Comments
-------------------------
LACNIC staff believes this proposal will have no significant impact and finds that it would be appropriate to update the sections it mentions.

Impact of the policy on the registration system
-----------------------------------------------
This proposal would not require any modification to the registration system.

Privacy Policy