Remove the reference to an applicant's multihomed status from the policy on IPv4 assignments to end users

Original Language Español Date Published 22/11/2018 Last Modified 01/05/2018
Last Call for Comments Period 09/10/2018 - 13/11/2018 Date Ratified 20/11/2018 Implementation Date 22/11/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-11
Last version: 1
Presentations:

Summary

Section 2.3.3.4.3 (Applicant Status) of the IPv4 policy on direct assignments by LACNIC to end users assesses different requirements depending on whether an applicant is a multi-homed end user or planning to become one.

There are several reasons why evaluating this requirement does not make sense:

1) In many cases applicants may need stable addressing but may be unable to use NAT and private addresses, regardless of their multihoming status, particularly considering current SLA levels.
2) In some cases, multihoming is not a viable option because of the costs involved, particularly in remote areas where a single provider may be available.
3) The IPv6 policy has long since eliminated the multihoming requirement, so there is no point in including it in the case of IPv4.

This proposal seeks to simplify this evaluation and remove these barriers by unifying the requirements regardless of whether applicants use multihoming.

Rationale

Having different requirements for IPv4 and for IPv6 seems senseless, particularly considering how technologies and SLA levels have improved, meaning that in many cases there may be less need for multihoming.

Text

Current text:

O 2.3.3.4.3. Applicant Status
In addition, the applicant's multihomed or non-multihomed status also affects the evaluation of the application.

If the applicant is a multi-homed end user or can prove interconnection needs with other autonomous systems:

The size of the minimum IPv4 address assignment to a multihomed end user is a /24, while the maximum is a /21. In order to qualify for a block, the applicant must also satisfy the following requirements:

o If the user is not yet multihomed but is planning to become multihomed within a six-month window, or if the user is planning to establish interconnections with other autonomous systems during this window, a detailed justification must be presented.
o Justify the requested block size according to the utilization rate (section 2.3.3.4.2).
o Agree to renumber all blocks assigned by other ISPs within three months and return them to their original ISPs.

Requests for blocks larger than a /21 must also comply with the additional requirements established for non-multihomed end users as described below.

If the applicant is a non-multihomed end user:

The minimum size of IPv4 assignments to a non-multihomed end user is a /20 block. If their IPv4 addressing needs are lower than a /20, non-multihomed end users will need to contact their ISPs in order to obtain addresses.

In order to assign a /20 to an end user, the following requirements must also be met:

Have received a minimum assignment of 8 /24 prefixes from its Internet Service Provider.

Agree to renumber out of the previously assigned space within a period of 12 months and return it to its original provider. This requirement is mandatory for obtaining the requested /20 prefix. The assigned /20 prefix must be used to renumber out of the addressing previously assigned by its provider.

Additional assignments shall follow the policies set forth in Section 2.3.4 applicable to end users.

New text:

o 2.3.3.4.3. Assignment size and procedure
The applicant must justify that the assigned space will be announced from the applicant’s own autonomous system to at least one other autonomous system.

The minimum size of an IPv4 assignment to an end user is a /24 block; the maximum size is a /20, which must be justified according to the utilization rate (section 2.3.3.4.2).

The block that had previously been assigned must be renumbered and then returned within a period no longer than 6 months. Exceptionally, this period may be extended by an additional 6 months if it can be justified that there was not enough time to obtain the required resources and complete the renumbering process.

Additional assignments shall follow the policies set forth in Section 2.3.4 applicable to end users.

Additional Information

-

Timetable

Given that the text of policy proposal LAC-2018-11 is contained in the text of policy proposal LAC-2018-8, in order to avoid duplications, if both proposals reach consensus after the last call for comments, only the text of LAC-2018-8 will be used, thus avoiding the confusion that duplicate texts would create.

References

Other RIRs do not require multihoming, but simply justifying the need for additional address space.

Public Comments by LACNIC Staff

ANÁLISIS DE IMPACTO DEL STAFF DE LACNIC - Propuesta LAC-2018-11 - versión 1

LACNIC Staff's Interpretation of the Proposal
---------------------------------------------

Applicability:
------------ 

This proposal applies in the case of initial IPv6 allocations to end users.


Modifications to the current text
--------------------------------
The Policy Manual would be modified as follows:

• Paragraph 3 of Section 2.3.3.4.3. Applicant Status would be modified as follows:

o 2.3.3.4.3. Size of the assignment and procedure
The applicant must justify that the assigned space will be announced from the applicant’s own autonomous system to at least one other autonomous system.

The minimum size of an IPv4 assignment to an end user is a /24 and the maximum size is a /20, which must be justified according to the utilization rate (section 2.3.3.4.2).

The block that had previously been assigned must be renumbered and returned within 6 months. Exceptionally, this period may be extended by an additional 6 months if it can be justified that there was not enough time to obtain the required resources and complete the renumbering process.

Additional assignments shall follow the policies set forth in Section 2.3.4 applicable to end users.

LACNIC Staff Comments:
-------------------------
The following parts of the current text are maintained:

• The need to justify the requested resources
• Minimum and maximum assignment sizes
• The request to renumber and return to the provider the block that had previously been assigned

The following changes are introduced:

• The multihoming requirement is eliminated
• The proposal considers the possibility of extending the period for returning the block for another 6 months if justified
• The term for returning the IP addresses to their provider is extended from 3 to 6 months
• In order to approve a request for IPv4 and IPv6 resources, LACNIC understands that the end user must have previously requested an ASN from LACNIC

Our recommendation is that the proposal should clarify the following: “The block that had previously been assigned must be renumbered and returned to the provider who assigned the block within 6 months.”

Impact of the policy on the registration system and address management
-------------------------------------------------------------------------
This proposal would not require any changes to the registration system.

Privacy Policy