[ppml] Policy Proposal: IPv6 Assignment Size Reduction - AC did not accept

[Member Services]

On 15 November 2007, the ARIN Advisory Council (AC) concluded its
review of the proposed policy 'IPv6 Assignment Size Reduction' and did
not accept it as a formal policy proposal. The AC provided the following
explanation of their decision: "The reason we do not accept it is
because there has not been any support on the Public Policy Mailing List."

During the initial review period the AC may decide to:
1)  Accept the proposal as a formal policy proposal as written.
2)  Postpone their decision regarding the proposal until the next
regularly scheduled AC meeting in order to work with the author.
3)  Not accept the policy proposal.

In the event that the AC decides not to accept the proposal, then the
author may elect to use the petition process to advance the proposal.
For petition details see the section called "Petition Process" in the
ARIN Internet Resource Policy Evaluation Process which can be found at:
http://www.arin.net/policy/irpep.html

The deadline for the author to initiate a petition per the ARIN Internet
Resource Policy Evaluation Process is 40 days prior to the meeting; the
petition deadline for the ARIN XXI Public Policy Meeting is 23:59 EDT,
27 February 2008. If the author chooses not to petition or the petition
is unsuccessful, then the proposed policy is closed. If a petition is
successful, then the proposal will be numbered and posted for discussion
and presented at ARIN's Public Policy Meeting.

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Policy Proposal Name: IPv6 Assignment Size Reduction

Author: Brian Dickson

Proposal Version: 1

Submission Date: Oct 18, 2007

Proposal type: modify

Policy term: permanent

Policy statement:

6.5.4.1. Assignment address space size

End-users are assigned an end site assignment from their LIR or ISP. The
exact size of the assignment is a local decision for the LIR or ISP to
make, using a minimum value of a /120 (when only one subnet is
anticipated for the end site) up to the normal maximum of /48, except in
cases of extra large end sites where a larger assignment can be justified.

The following guidelines may be useful (but they are only guidelines):

     * /120 for a very small customer with one subnet, using static
assignments or DHCPv6
     * /116 for a small customer with a few subnets, using static
assignments or DHCPv6
     * /112 for a medium size customer with a significant total number
of hosts and/or subnets, using static assignments and/or DHCPv6
     * /96 for large customers
     * /80 for very large customers, or for customers using a proposed
modified version of V6-autoconf (which uses EUI-48 instead of EUI-64)
     * /72 for customers with several subnets using modified V6-autoconf
(which uses EUI-48 instead of EUI-64)
     * /64 when it is known that one and only one subnet is needed, for
a customer that absolutely requires either traditional IPv6
autoconfiguration, or IPv6 host Interface Identifier cryptographic
generation
     * /60 for sites where a mix of IPv6-autoconfiguration and other
address assignment techiques are required
     * /56 for very large sites
     * /52 for very, very large sites
     * /48 for extremely large sites

For end sites to whom reverse DNS will be delegated, the LIR/ISP should
consider making an assignment on a nibble (4-bit) boundary to simplify
reverse lookup delegation.

Rationale:

The intent is to provide more current guidance, to both ARIN members,
and to ARIN staff, based on available IPv6 technology, and for the
encouragement of efficient assignment of IPv6 address space.

IPv6 supports numerous methods for address assignments to end nodes.
Those include autoconfiguration, static assignment, and DHCPv6.
Of those, only autoconfiguration requires use of /64 as the prefix size.

Efficient use of IPv6 space should discourage widespread use of /64's,
or for use of autoconfiguration as the sole justification for
allocations of large address space.

In particular, the effective lifetime of PA assignments to ISPs/LIRs, is
largely a factor of internal aggregation, and the size of end assignments.

Rather than meeting ISP needs by assigning very large IPv6 PA blocks, it
would be wiser to encourage assignments that to not significantly use up
available PA space for the ISP, even for very large customers.

The overall intent is to minimize the need for any PA recipient, to
return to ARIN for subsequent assignments, thus reducing the need for
additional globally routable prefixes using up slots in routers in the
DFZ - something that affects the long-term ability for all ISPs to
continue to scale in a cost-effective manner.

Timetable for implementation: Immediate