Six Internet Policy Proposals for the Region


Six Internet Policy Proposals for the Region

Six policy proposals related to how Internet numbering resources are managed in the region will be analyzed and discussed during the Public Policy Forum at the LACNIC event that will be held in Cuba during the first week of May.

Submitted by members of the community, these proposals have already been discussed on the LACNIC Policy mailing list. Should consensus be reached in Cuba, they will continue the process towards their final implementation. The forum is open to the public and anyone interested in doing so may participate.

Proposals to be discussed

A Single Protocol. Juan José Gaytán Hernández Magro (Alestra) has proposed a way to settle IPv4-IPv6 connectivity disputes when only one of the protocols is supported. He promotes establishing a recommendation or approach for settling the IPv4-IPv6 connectivity disputes that arise when an IPv4-only network or carrier wishes to communicate with an IPv6-only network. According to Mr. Gaytán, users that only support IPv4 should upgrade their infrastructure to support dual stack to be able to use IPv6.

Critical Infrastructure. Edmundo Cazarez-Lopez (NIC Mexico) presented a proposal for creating an IPv4 reserve pool for infrastructure considered critical or essential for Internet operation in the region. This initiative seeks to create an IPv4 reserve pool equivalent to a /15 that is independent from the reserves created for IPv4 exhaustion. These addresses would be used to satisfy requests for resources that will be used to deploy infrastructure considered critical or essential for the operation of the Internet in the LAC region.

One Less Requirement. Julião Braga has proposed that the LACNIC community remove the reference to an applicant’s “multihomed or non-multihomed” status. Removing the reference to a provider’s “multihomed or non-multihomed status” would also eliminate the requirement that mentions “utilization of at least 50% of the requested address space” and harmonizing this text as “25% of the requested address space.”

IPv6 Assignments to End Users. Another proposal that will be discussed during LACNIC 25 is the change promoted by Jordi Palet Martinez (Consulintel) regarding the modification of direct IPv6 assignments to end users. According to the author, “this policy was designed based on its IPv4 equivalent and some of its considerations make no sense in IPv6.” This proposal seeks to modify the text so that it will be consistent with actual IPv6 usage.

Initial IPv6 Allocations. Jordi Palet has also proposed modifying the size of initial IPv6 allocations. According to Mr. Palet, when the policy was originally drafted the authors failed to consider the case of organizations that are not strictly ISPs in the traditional sense of the term but are instead government agencies, academic networks or other similar cases. Because of their size, number of users, extent of their infrastructure, hierarchical and/or geographic structure, or other reasons, etc., under the current text of the policy these organizations might not be able to justify the need for an allocation larger than a /32 as required by the current text of the policy.

Thus, Mr. Palet proposes creating a new section for this type of organizations: “Initial allocation size for LIRs that are not ISPs (governments, associations, academic networks or other similar cases).”

Size and subsequent direct IPv6 assignments to end sites. In addition, Jordi Palet submitted a third proposal to modify an IPv6 policy, this one involving the size and subsequent direct IPv6 assignments to end users.

In his opinion, the policy currently limits the maximum size of assignments, so he proposes that addresses should always be assigned in blocks larger than or equal to a /48 and that, where possible, such assignments should be made from a contiguous address block.

The proposal seeks to modify the text so that it will be consistent with the reality of IPv6, in which, according to Mr. Palet, placing limitations on actual needs makes no sense.

Notify of

Inline Feedbacks
View all comments