[arin-ppml] Petition for discussion of policy proposal 116 (Permitted Uses of Space Reserved Under NRPM 4.10)

[Hannigan, Martin]

Hi Owen,

I don’t support this petition. The work the ideas are good, but they were germane twelve months ago, not now. There is sentiment to set aside an entire /8 and be use it for only transition purposes and to help defray post exhaustion costs. This doesn’t go far or wide enough IMHO and I don’t see what you could compromise to make it acceptable.

Best Regards,

Martin Hannigan






On 7/21/10 2:19 AM, "Owen DeLong" <owen at delong.com> wrote:

The AC abandoned the following proposal:

 116. Permitted Uses of space reserved under NRPM 4.10

The AC voted to abandon this proposal because of a lack of sufficient
support to accept it as draft policy. Several AC members felt it not
appropriate that ARIN policy dictate any specific architecture or method
a network should use to transition from v4 to v6.

This is my formal request to initiate a discussion petition of proposal 116.

If you would like to sign this petition, please do the following:

1. Send a message stating "I support the petition for discussion of proposal 116"
to arin-ppml at arin.net

2. Either include your contact information and organizational affiliation in
the original message to ppml or send it in a separate message to
petition at arin.net (use this address if you do not want your contact
information disclosed to PPML).

Thank you.

I believe that the AC should not have abandoned this proposal for the following
reasons:

1. I believe that there is community support for clarifying valid uses and
preventing abuses of space reserved for transitional technologies under
section 4.10.

2. The language of 116 states examples of valid uses of space under 4.10
but does not specify or dictate specific architecture or methods. It attempts
to prevent space reserved for transition from being used in a business-as-
usual method that is not in direct support of a transition to IPv6 because
the author believes that is contrary to the community intent of 4.10.

I refer specifically to 4.12(1)(a-e) which list a multitude of possible valid
technologies and includes specifically (e) etc. to cover any possible
valid technologies not yet contemplated.

3. The language in the existing 4.10 is not sufficiently specific to prevent
a multitude of possible abuses of the reserved space that do not actually
benefit a transition process.

For these reasons, I encourage anyone who feels that section 4.10 reflects the
good intent of the community to sign this discussion petition to get this policy
in front of the community in Atlanta. Even if you disagree with the specifics, those
can be addressed in the development of the policy. If you have comments on
those specifics, please direct them to ppml or to me.


Author contact information as required in the petition process:

Owen DeLong
owen at delong.com
+1.408.890.7992

Here is the text of the proposal in question as required in the petition
process:

Policy Proposal 116: Permitted Uses of space reserved under NRPM 4.10
Proposal Originator: Owen DeLong
Proposal Version: 1
Date: 18 June 2010
Proposal type: modify
Policy term: permanent
Policy statement:
Add the following to section 4.10 of the NRPM
6. No organization may receive more than 16 /24 equivalents under this
section.
Add the following to section 4 of the NRPM
4.11 Required utilization for subsequent allocation under section 4.10
No organization shall receive more than one allocation or assignment
under section 4.10 unless all prior space issued under 4.10 meets the
utilization requirements of this section.
1. The most recent 4.10 allocation/assignment must be at least 80% utilized.
2. All utilization must be permitted under section 4.12
3. All prior 4.10 allocation/assignments must be at least 90% utilized.
4.12 Permitted uses of allocations or assignments under section 4.10
No organization shall use space received under section 4.10 for any
purpose other than as specified in this section
1. To provide the required public IPv4 address(es) for transitional
technologies operated by the recipient organization.
a. Large scale or "Carrier Grade" NAT
b. NAT-PT
c. DS-LITE/AFTeR
d. DNS64 or other transitional DNS enablers
e. etc.
2. For other transitional technologies not envisioned at the time of
this proposal, but, in no case for general IPv4 addressing provided to
customers.
Rationale:
The current terminology in section 4.10 is vague and could allow a
variety of interpretations which could lead to allocations or
assignments being made to ISPs intending to misuse the space for general
deployment by using IPv6 overlay technologies as a "IPv6 deployments"
requiring IPv4 space for transition. For example, the current policy
could be interpreted to enable an ISP to require IPv4 addresses for all
IPv6 customers to roll IPv6 out as 6rd to customers who would be
otherwise unable to get IPv4 space. This is clearly outside of the
original intent of the proposal which created 4.10 (6rd was not yet
envisioned at the time that was written). This proposal seeks to clarify
that intent and tighten up the requirements for organizations seeking to
get space from this limited final resource so that it truly is available
to facilitate transitional technologies.
Timetable for implementation: immediate
For reference, here is the current text of 4.10
4.10 Dedicated IPv4 block to facilitate IPv6 Deployment
When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous
/10 IPv4 block will be set aside and dedicated to facilitate IPv6
deployment. Allocations and assignments from this block must be
justified by immediate IPv6 deployment requirements. Examples of such
needs include: IPv4 addresses for key dual stack DNS servers, and NAT-PT
or NAT464 translators. ARIN staff will use their discretion when
evaluating justifications.
This block will be subject to a minimum size allocation of /28 and a
maximum size allocation of /24. ARIN should use sparse allocation when
possible within that /10 block.
In order to receive an allocation or assignment under this policy:
1. the applicant may not have received resources under this policy in
the preceding six months;
2. previous allocations/assignments under this policy must continue to
meet the justification requirements of this policy;
3. previous allocations/assignments under this policy must meet the
utilization requirements of end user assignments;
4. the applicant must demonstrate that no other allocations or
assignments will meet this need;
5. on subsequent allocation under this policy, ARIN staff may require
applicants to renumber out of previously allocated / assigned space
under this policy in order to minimize non-contiguous allocations.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100726/4aee8f06/attachment.htm>