[ppml] PPML Digest, Vol 28, Issue 56

As previously stated this breaks existing implementations
as well as contradicting a large number of RFCs.
It is in direct conflict with current IETF direction.

The current guidelines of:
/56 for small sites
/48 for large sites
And
/32 or larger for LIRs is reasonable.

The only further comment I have on this is NO!

LR Mack McBride
Network Administrator
Alpha Red, Inc.

>
> Message: 5
> Date: Mon, 22 Oct 2007 11:23:21 -0400
> From: Member Services <info at arin.net>
> Subject: [ppml] Policy Proposal: IPv6 Assignment Size Reduction
> To: ppml at arin.net
> Message-ID: <471CC069.6040005 at arin.net>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> 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
>
>
>
>
>
> ------------------------------
>
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml
>
>
> End of PPML Digest, Vol 28, Issue 56
> ************************************