[ppml] Policy Proposal Name: IPv6 Assignment Size Reduction

Wed Nov 14 13:09:08 EST 2007

I agree completely with Yurie. This proposal only proves that the  
policy-makers at ARIN are incapable of thinking in the IPv6 paradigm,  
and continue to think that IPv6 is IPv4 with larger address space.

On Nov 14, 2007, at 11:28 AM, Rich, Yurie wrote:

> For reasons too numerous to list here, I’ll simply state that I, my  
> company – Command Information, and many of the customers I  
> represent, including the IPv6 Business Council, strongly oppose this  
> policy proposal.  Not only does it fundamentally break numerous  
> structures in IPv6 environments, it is attempting to solve a problem  
> that doesn’t exist.  I applaud efforts to learn from our previous  
> mistakes and integrate a conservationist mindset for IPv6 address  
> allocation, but I don’t believe this policy will accomplish that.
>
> Regards,
>
> Yurie Rich
> Director, IPv6 Services Group
> Command Information
>
>
> > 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.
> >
>
>
>
>
> <image001.jpg>
> Powered by CardScan
>
> _______________________________________________
> 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.

--
Cort Buffington
Assistant Director for Technical Services
The Kansas Research and Education Network
cort at kanren.net
Office: +1-785-856-9800 x301
Mobile: +1-785-865-7206