[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fwd: [ppml] Policy Proposal: IPv6 Assignment Size Reduction
On Mon, 29 Oct 2007 22:31:10 +0100
Iljitsch van Beijnum <iljitsch@muada.com> wrote:
> I thought this would be interesting reading for the working group.
>
I think the best thing to do is ignore it. If it gets any traction in
ARIN, then we might have to do something.
(I'm embarrassed to be listed in the acknowledgements section of the
related draft, because it can imply I agree with it - and my position is
the complete opposite - I'm even fairly strongly anti-/56.)
> Note that this is just one individual proposing a new policy, which is
> about the same thing as writing an individual submission draft in the
> IETF.
>
> Begin forwarded message:
>
> > From: Member Services <info@arin.net>
> > Date: 22 oktober 2007 17:23:21 GMT+02:00
> > To: ppml@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@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@arin.net if you experience any issues.
>
>