[ppml] Policy Proposal: IPv6 Assignment Size Reduction

[Tony Hain]

This proposal is completely misguided, in that its fundamental premise is
based on the IPv4 mindset of managing subnet size based on connected device
count. This short-sighted approach precludes technology advancements like
securing neighbor discovery through use of cryptographic addressing
mechanisms. 

While any organization is free to choose whatever prefix length it wants
(with the associated self-inflicted consequences), it is inappropriate for
assignment policy to placate this closed-minded and unjustified
conservatism. People are complaining about routers falling over due to too
many routing entries, yet proposals like this one keep appearing that do
nothing more than increase the number of potential routing entries at the
expense of real innovation. 

IPv6 has many of the characteristics of IPv4, to make deployment straight
forward for the existing staff. That similarity does not mean IPv6 should be
limited to the capabilities of IPv4, yet proposals like this one (and
statements like 'IPv6 is just IPv4 with more bits') are so focused on the
past that they attempt to ensure that IPv6 can never have new and different
capabilities.

I oppose this proposal.

Tony 


> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of
> Member Services
> Sent: Monday, October 22, 2007 8:23 AM
> To: ppml at arin.net
> Subject: [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
> 
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN
> Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN
> Member Services
> Help Desk at info at arin.net if you experience any issues.