[arin-ppml] Draft Policy 2010-12: IPv6 Subsequent Allocation

[Ted Mittelstaedt]

On 7/20/2010 11:12 AM, Member Services wrote:
> Draft Policy 2010-12
> IPv6 Subsequent Allocation
>
> On 15 July 2010 the ARIN Advisory Council (AC) selected "IPv6 Subsequent
> Allocation" as a draft policy for adoption discussion on the PPML and at
> the Public Policy Meeting in Atlanta in October.
>
> The draft was developed by the AC from policy proposal "118. IPv6
> Subsequent Allocation". Per the Policy Development Process the AC
> submitted text to ARIN for a staff and legal assessment prior to its
> selection as a draft policy. Below the draft policy is the ARIN staff
> and legal assessment, followed by the text that was submitted by
> the AC.
>
> Draft Policy 2010-12 is below and can be found at:
> https://www.arin.net/policy/proposals/2010_12.html
>
> You are encouraged to discuss Draft Policy 2010-12 on the PPML prior to
> the October Public Policy Meeting. Both the discussion on the list and
> at the meeting will be used by the ARIN Advisory Council to determine
> the community consensus for adopting this as policy.
>
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
>
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/policy/proposals/index.html
>
> Regards,
>
> Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Draft Policy 2010-12
> IPv6 Subsequent Allocation
>
> Version/Date: 20 July 2010
>
> Policy statement:
>
> Modify 6.5.2.1 Subsequent allocation criteria. ADD the following
> sentence: Subsequent allocations will also be considered for
> transitional technologies that cannot be accommodated by, nor were
> accounted for, under the initial allocation.
>
> Justification for the subsequent subnet size will be based on the plan
> and technology provided. Justification for these allocations will be
> reviewed every 3 years and reclaimed if it is not in use. Requester will
> be exempt from returning all or a portion of the address space if they
> can show justification for need of this allocation for other existing
> IPv6 addressing requirements be it Native V6 or some other V6 network
> technology.
>
> Rationale: Current organizations cannot get an allocation for a IPv6
> transitional technology if they have already received their initial
> allocation of IPv6. The reason they cannot get an additional IPV6
> allocation is because they don't meet the HD ratio for a subsequent
> allocation and they don't want to use their initial assignment because
> it is insufficient, mapped out for other long term plans, or already has
> portions in use.
>
> An alternative proposal to permit more allocations was submitted that
> supported 6rd but since then community members have come forward with
> concern that this should support not just one particular technology but
> any that enable v6 deployment.
>
> Justification Example: Below is an example of how the details for a
> technology and its subnet requirements could be provided as
> justification. This example is based of 6rd.
>
> 6rd is intended to be an incremental method for deploying IPv6 and
> bridge the gap for End Users to the IPv6 Internet. The method provides a
> native dual-stack service to a subscriber site by leveraging existing
> infrastructure. If an entity already has a /32 of IPv6 they can not use
> the same /32 for native IPv6 as they do for the 6rd routing and a
> separate minimum size of a /32 is required while a larger subnet like a
> /28 may be needed based on a non-contiguous IPv4 addressing plan.
>
> The 6rd prefix is an RIR delegated IPv6 prefix. It must encapsulate an
> IPv4 address and must be short enough so that a /56 or /60 can be given
> to subscribers. This example shows how the 6rd prefix is created based
> on a /32 IPv6 prefix using RFC1918 address space from 10.0.0.0/8:
>
> SP IPv6 prefix: 2001:0DB8::/32 v4suffix-length: 24 (from 10/8, first
> octet (10) is excluded from the encoding) 6rd CE router IPv4 address:
> 10.100.100.1 6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56
>
> This example shows how the 6rd prefix is created based on a /28 IPv6
> prefix using one of several non-contiguous global address ranges:
>
> SP IPv6 prefix: 2001:0DB0::/28 v4suffix-length: 32 (unable to exclude
> common bits due to non-contiguous IPv4 allocations) 6rd CE router IPv4
> address: 192.0.2.1 6rd site IPv6 prefix: 2001:0DBC:0000:2010::/60
>
> Timetable for implementation: Immediate
>
>
> #####
>
>
> STAFF ASSESSMENT
>
> Proposal: (118) IPv6 Subsequent Allocation
> Proposal Version (Date): 21 June 2010
> Date of Assessment: 14 July 2010
>
> 1. Proposal Summary (Staff Understanding)
>
> This policy opens the IPv6 ISP additional allocation policy to allow for
> subsequent allocations to be considered when a new technology is being
> implemented which requires a separate block from existing IPv6
> allocations. Subsequent allocations issued under this new language must
> be reviewed with the registrant every 3 years by ARIN staff.
>
> 2. Comments
>
> A. ARIN Staff Comments
>
> • The policy text provides no concrete criteria for ARIN staff to
> determine when an organization does, or does not, qualify for a
> subsequent IPv6 allocation.
> • Additionally, there are no criteria to be used to determine the size
> of the allocation an organization qualifies for. For example, if an
> organization says they need 32 bits for encapsulating the IPv4 address,
> and wants to give a /48 to each customer, they would need a /16 of IPv6
> space. Current IPv6 policy provides clear criteria for judging the
> subsequent allocation size by applying an hd ratio of .94, a criterion
> which can be applied consistently across the board. This policy would
> have staff determining subsequent allocation based on “some technical
> documentation” without any real guidelines. Should staff be approving
> any request for subsequent IPv6 allocations of any size whenever the
> justification is “we’re using it for a transitional technology”?
>
> B. ARIN General Counsel
>
> No comments at this time. It is unlikely to raise legal issues.
>
> 3. Resource Impact
>
> This policy would have minimal resource impact. It is estimated that
> implementation would occur within 3 months after ratification by the
> ARIN Board of Trustees. The following would be needed in order to
> implement:
> • Updated guidelines
> • Staff training
>
>
> 4. Proposal Text
>
> Policy statement:
>
> Modify 6.5.2.1 Subsequent allocation criteria. ADD the following
> sentence: Subsequent allocations will also be considered for
> transitional technologies that cannot be accommodated by, nor were
> accounted for, under the initial allocation.
> Justification for the subsequent subnet size will be based on the plan
> and technology provided. Justification for these allocations will be
> reviewed every 3 years and reclaimed if it is not in use. Requester will
> be exempt from returning all or a portion of the address space if they
> can show justification for need of this allocation for other existing
> IPv6 addressing requirements be it Native V6 or some other V6 network
> technology.
>
> Rationale:
> Current organizations cannot get an allocation for a IPv6
> transitional technology if they have already received their initial
> allocation of IPv6. The reason they cannot get an additional IPV6
> allocation is because they don't meet the HD ratio for a subsequent
> allocation and they don't want to use their initial assignment because
> it is insufficient, mapped out for other long term plans, or already has
> portions in use.
>
> An alternative proposal to permit more allocations was submitted that
> supported 6rd but since then community members have come forward with
> concern that this should support not just one particular technology but
> any that enable v6 deployment.
> Justification Example:
> Below is an example of how the details for a technology and its subnet
> requirements could be provided as justification. This example is based
> of 6rd.
>
> 6rd is intended to be an incremental method for deploying IPv6 and
> bridge the gap for End Users to the IPv6 Internet. The method provides
> a native dual-stack service to a subscriber site by leveraging existing
> infrastructure. If an entity already has a /32 of IPv6 they can not use
> the same /32 for native IPv6 as they do for the 6rd routing and a
> separate minimum size of a /32 is required while a larger subnet like a
> /28 may be needed based on a non-contiguous IPv4 addressing plan.
> The 6rd prefix is an RIR delegated IPv6 prefix. It must encapsulate an
> IPv4 address and must be short enough so that a /56 or /60 can be given
> to subscribers. This example shows how the 6rd prefix is created based
> on a /32 IPv6 prefix using RFC1918 address space from 10.0.0.0/8:
> SP IPv6 prefix: 2001:0DB8::/32
> v4suffix-length: 24 (from 10/8, first octet (10) is excluded
> from the encoding)
> 6rd CE router IPv4 address: 10.100.100.1
> 6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56
> This example shows how the 6rd prefix is created based on a /28 IPv6
> prefix using one of several non-contiguous global address ranges:
> SP IPv6 prefix: 2001:0DB0::/28
> v4suffix-length: 32 (unable to exclude common bits
> due to non-contiguous IPv4 allocations)
> 6rd CE router IPv4 address: 192.0.2.1
> 6rd site IPv6 prefix: 2001:0DBC:0000:2010::/60
>

I do not like this proposal at all for 3 reasons:

1)the only language in it that even acknowledges that these allocations 
are intended to be temporary is the line:

"...Justification for these allocations will be
reviewed every 3 years and reclaimed if it is not in use...."

What your doing is allowing an org to request space for a band-aid and
by not putting a deadline on it your going to just allow them to
institutionalize the bandaid.  That's not what we should be encouraging.

I would prefer the proposal only allocated the temp space for a fixed
period of time, and then if it wasn't returned by the deadline of that
time, the space would then be added to their HD ratio calculation for
subsequent allocations.  No need to waste staff time at the RIR going
back and reviewing every 3 years.

2)  I would much prefer that instead of the RIR's allowing these
special allocations willy-nilly across the IPv6 space, that IANA
designate a special prefix for each transitional technology that is
worked out, and that special allocations be made from that prefix.
It would make things a lot easier 10 years from now when orgs want to
filter out some of these at-that-time-dead bandaid technologies.

I see no reason to commence "infill" activites on IPv6 now.  We are
not trying to build a city here.  And yes I realize 1 and 2 aren't
really compatible.  Pick one or the other..

If IANA won't setup to the plate for this then if ARIN is going to
adopt this then I would prefer ARIN designate a specific block for
IPv6 temporary special allocations and make all of them from that
prefix.

3) I feel that this proposal and the 6rd proposal are exclusive.
I would prefer multiple "transitional IPv6 technologies" proposals
that are like the 6rd proposal for each new "transitional technology"
that is invented, rather than a one-size-fits-all transitional
technology proposal.


Ted