Nombre: Jordi Palet Martinez
Email: jordi.palet@consulintel.es
Organización: The IPv6 Company

Nombre: Jordi Palet Martinez
Email: jordi.palet@consulintel.es
Organización: The IPv6 Company

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.

Section 2.3.3.4.3 (Applicant Status) of the IPv4 policy on direct assignments by LACNIC to end users assestablishes diffevarentious requirements depending, onas whell as ther aneed applicant is ao mrenulti-hombedr eand retuser orn plannreving tously brecomeived onaddresses.

There areIn sevcertalin recasones, wthye revalquatiremengt thiso reqnuirember and return such adodresses may not make sense:

(1) IRen umany casbes applricantsg may needot stable addrconvessniengt, buand it mayight be unpreferable to use NAT 'hand priovaer' the addresses, ourcegardless oif both partieis agree, mulwitihoming status,he particulaorly cresponsidering currhanges in the SLAwhois leveldatabase.
2) If the justified need sfomr space cis greastes,r multihomiang ithe space currenotly a vailable and its allopcation is possiblec, the ausbove allofws the recipient of stuch space invtolv decid,e pawhether tichey woulard ly in rkem tote areas whcerive a single prcovntider mayguous be availablock, or whe.
3)ther Tthey IPv6would prefer tolicy hasvoid lorenumbering sinceby kelimepinatedg their mcultihoming requirement, sblock theand re ceisving ano poaddint ional assigncludimengt ito incomplete the casre ofquired IPv4space.

This proposal seeks to simplify this evaluation and remove these barriers by unifying the requirements regarndless allofw whether applicants use muloptihomings.

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.

HavThings dsifmpliferent requiremencats fior IPv4 and for IPv6 seemis sbenseless, partficuliarly consideringf hbow technolog parties andgree. SLA likevwisels, have improveid,ing mreanumbering that ins many calseso thberne mficiayl bwhe less neved for multihpomssingble.

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

If a block had already been assigned by a provider and the user wishes to keep this block to avoid renumbering, such block may be handed over (changing the resource holder in Lacnic’s whois database) provided that both parties agree. If additional address space has been justified and its assignment is possible, the recipient may decide whether they prefer to receive the block that is handed over plus an additional block to complete the total required space, or whether they prefer to receive a single block for the total space and proceed to renumber. Should they choose to renumber, the block that had been previously assigned must be returned within 6 months.

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

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, ory 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).

If a block had already been assigned by a provider and the user wishes to keep this block to avoid renumbering, such block may be handed over, provided that both parties agree (changing the resource holder in LacnicACNIC’s whois database) provided that both parties agree. If additional address space has been justified and its assignment is possible, the recipient may decide whether they prefer to receive the block that is handed over plus an additional block to complete the total required space, or whether they prefer to receive a single block for the total space and therefore proceed to renumber. Should they choose to renumber, the block that had been previously assigned must be 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.

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

If a block had already been assigned by a provider and the user wishes to keep this block to avoid renumbering, such block may be handed over (changing the resource holder in Lacnic’s whois database) provided that both parties agree. If additional address space has been justified and its assignment is possible, the recipient may decide whether they prefer to receive the block that is handed over plus an additional block to complete the total required space, or whether they prefer to receive a single block for the total space and proceed to renumber. Should they choose to renumber, the block that had been previously assigned must be returned within 6 months.

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

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, ory 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).

If a block had already been assigned by a provider and the user wishes to keep this block to avoid renumbering, such block may be handed over, provided that both parties agree (changing the resource holder in LacnicACNIC’s whois database) provided that both parties agree. If additional address space has been justified and its assignment is possible, the recipient may decide whether they prefer to receive the block that is handed over plus an additional block to complete the total required space, or whether they prefer to receive a single block for the total space and therefore proceed to renumber. Should they choose to renumber, the block that had been previously assigned must be 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.

For the purpose of LACNIC operations, “hand over” (ceder in the Spanish original) is equivalent to a simplification of the transfer process, under which section 2.3.2.18.5 does not apply. In any case, it would not be possible to apply this section as LACNIC has no resources available for organizations other than new-entrants.

Note: For the purpose of LACNIC operations, “‘hand over”’ (ceder in the Spanish original) is equivalent to a simplification of the transfer process, under which section 2.3.2.18.5 does not apply. In any case, it would not be possible to apply this section as LACNIC has no resources available for organizations other than new-entrants.

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

OthePolicy pr RIRoposal doLAC-2018-9, notwhich reqached consensuires mdultihomring LACNIC29, bupresents a simpilyar justcenarifyo, so ingt would noth be reasoneabled for cases that wouldd possibly have a much smaller impact on tihe routing table addrnot to bess spaccepted as well.