ARIN-PPML Message

[ppml] Policy Proposal: IPv6 Assignment Size Reduction

ARIN received the following policy proposal. In accordance with the ARIN
Internet Resource Policy Evaluation Process, the proposal is being
posted to the ARIN Public Policy Mailing List (PPML) and being placed on
ARIN's website.

The ARIN Advisory Council (AC) will review this proposal at their next
regularly scheduled meeting. The AC may decide to:

    1. Accept the proposal as a formal policy proposal as written. If the
AC accepts the proposal, it will be posted as a formal policy proposal
to PPML and it will be presented at a Public Policy Meeting.

    2. Postpone their decision regarding the proposal until the next
regularly scheduled AC meeting in order to work with the author. The AC
will work with the author to clarify, combine or divide the proposal. At
their following meeting the AC will accept or not accept the proposal.

    3. Not accept the proposal. If the AC does not accept the proposal,
the AC will explain their decision. If a proposal is not accepted, then
the author may elect to use the petition process to advance their
proposal. If the author elects not to petition or the  petition fails,
then the proposal will be closed.

The AC will assign shepherds in the near future. ARIN will provide the
names of the shepherds to the community via the PPML.

In the meantime, the AC invites everyone to comment on this proposal on
the PPML, particularly their support or non-support and the reasoning
behind their opinion. Such participation contributes to a thorough
vetting and provides important guidance to the AC in their deliberations.

The ARIN Internet Resource Policy Evaluation Process can be found at:
http://www.arin.net/policy/irpep.html

Mailing list subscription information can be found at:
http://www.arin.net/mailing_lists/

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