From info at arin.net Mon Nov 5 14:41:51 2007 From: info at arin.net (Member Services) Date: Mon, 05 Nov 2007 14:41:51 -0500 Subject: [ppml] Policy Proposal: IPv6 Assignment Size Reduction In-Reply-To: <471CC069.6040005@arin.net> References: <471CC069.6040005@arin.net> Message-ID: <472F71FF.3060008@arin.net> > The AC will assign shepherds in the near future. ARIN will provide > the names of the shepherds to the community via the PPML. The shepherds from the ARIN Advisory Council for this proposal are Alec Peterson and Bill Darte. Regards, Member Services American Registry for Internet Numbers (ARIN) Member Services wrote: > 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. > From info at arin.net Mon Nov 5 14:42:54 2007 From: info at arin.net (Member Services) Date: Mon, 05 Nov 2007 14:42:54 -0500 Subject: [ppml] Policy Proposal: 200-reduction-6.5.1.1.d In-Reply-To: <471CC078.2060401@arin.net> References: <471CC078.2060401@arin.net> Message-ID: <472F723E.6050701@arin.net> > The AC will assign shepherds in the near future. ARIN will provide > the names of the shepherds to the community via the PPML. The shepherds from the ARIN Advisory Council for this proposal are Paul Andersen and Bill Darte. Regards, Member Services American Registry for Internet Numbers (ARIN) Member Services wrote: > 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: 200-reduction-6.5.1.1.d > > Author: Brian Dickson > > Proposal Version: 1 > > Submission Date: Oct 18, 2007 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > In 6.5.1.1 d), where 2007-25 proposes: > > "be an existing, known ISP in the ARIN region or have a plan for making > at least 200 end-site assignments to other organizations within 5 years." > > replace with" > "be an existing, known ISP in the ARIN region or have a plan for making > at least 20 end-site assignments to other organizations, or for > providing IPv6 transit to one or more IPv6 PI blocks belonging to other > organizations, within 5 years." > > Rationale: > > The purpose of the text is to establish reasonable ways for an ISP to > demonstrate that it is in fact an ISP. Any of the above listed > conditions satisfy that need, and the intent is to avoid having the text > of the policy prevent any legitimate ISP from receiving an initial IPv6 > allocation. > > It does lower the bar, but in a justifiable fashion. It is not necessary > for an ISP to have lots of PA assignments. It is necessary for an ISP to > be announcing PA *or* PI blocks to the internet, and relaxing the > criteria to recognize both possibilities jointly, makes the policy > reflect the actual realities for any number of large regional ISPs, who > may have sold off portions of their business but who still operate > significant infrastructure. > > 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. > From info at arin.net Mon Nov 5 14:47:24 2007 From: info at arin.net (Member Services) Date: Mon, 05 Nov 2007 14:47:24 -0500 Subject: [ppml] Policy Proposal: globally-coordinated-RIR-pie-IPv4 In-Reply-To: <472646C9.3000207@arin.net> References: <472646C9.3000207@arin.net> Message-ID: <472F734C.60803@arin.net> > The AC will assign shepherds in the near future. ARIN will provide > the names of the shepherds to the community via the PPML. The shepherds from the ARIN Advisory Council for this proposal are Paul Andersen and Stacy Taylor. Regards, Member Services American Registry for Internet Numbers (ARIN) Member Services wrote: > 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: globally-coordinated-RIR-pie-IPv4 > > Author: Brian Dickson > > Proposal Version: 1 > > Submission Date: 26 October 2007 > > Proposal type: new > > Policy term: renewable > > Policy statement: > > This policy concerns the globally-coordinated allocations of IPv4 > address space from IANA to the RIRs. > > The policy is intended to be compatible with 2007-23 (in its expected > final form). > > The overview of the policy is: > At the last reasonable time to do so, divide up the remaining IPv4 space > based on currently projected use between that time and the date at which > no more IPv4 space is available at any RIR for new allocations. > > Here is how the policy is to be implemented: > > 1) RIRs should provide up-to-date assignment projections for their > respective regions, and provide up-to-date utilization on their current > IANA-assigned block(s) from which assignments are made. > > 2) RIRs should provide an official projection on IANA Exhaustion Date > (IED) to the community through their website, at their Policy Meetings > and through any other effective means. > > 3) When any RIR requests a /8 from IANA, the current assignment > projections for that RIR should be combined with the RIR's currently > available IANA blocks (i.e. from which RIR assignments are made). This > should be compared with the global available IANA unused space (for > allocating to RIRs), the current projected usage rate of the RIR, and > the current projected IED. > > If the RIR projection shows that the RIR would not expect to use up two > /8 blocks before IED, the "Pie-splitting" event will be triggered. > > 4) Splitting the Pie - the following method will be used to determine > the final IPv4 global IANA allocations to the RIRs: > For each RIR, the following calculation will be done: > (i) Determine from the current projection, the total allocations > the RIR will make from present to IED > (ii) Subtract from this, unallocated RIR space already received > from ARIN (if any) > (iii) Round the result to the nearest /12 > (iv) Subtract from this amount, one /8 (to be set aside to satisfy > the 2005-23 policy proposal for "End Policy for IANA IPv4 allocations to > RIRs") > (v) Allocate this amount to the RIR immediately. Every effort > should be made to divide these allocations among RIRs in as aggregatable > a fashion as possible. > > 5) The allocations made will result in just 5 * /8 being left in the > IANA pool, which will trigger 2007-23. > > 6) This in turn, will result in the last 5 * /8's being allocate to the > RIR's, one for each. > > > Rationale: > > The objective of this policy is to ensure that the remaining IPv4 pool > is distributed so as to provide each RIR with a quantity of IPv4 > addresses that will last for an expected duration. > > The intent is for this duration to be as close to the same for each RIR > as possible. > > By following the rules above, the "pie split" is done: > - as late as possible > - as fairly as possible > - in a consistent manner for all RIRs > - early enough that each RIR is guaranteed at least one /8 > > The final /8 allocations are done *after* this allocation, so that there > can be no issue of fairness, with each RIR being guaranteed to get one > of the final /8's at the same time. > > The "pie split" is timed so that no RIR will have so much (relative) > IPv4 address space, as to expect to have IPv4 space after any other RIR > has exhausted its own IPv4 space. > > By providing a "pie split" which is based on the same data as the IED > projection, the following results occur: > - there is no contention over the process by which the division of > resources occur > - all RIRs have the ability to project, well in advance of the "pie > split", exactly when their own IPv4 space will be exhausted. It will > happen at the IED date -- no sooner, no later. > - No RIR "shopping" is likely to occur. Consequently, no inter-RIR "land > grab" is likely to occur, and thus the projections for IED itself are > likely to remain consistent, as will the per-RIR projections. > - LIRs are likely to view the policy as neutral, and thus fair. > - Because it removes the incentive for RIR shopping, the rules > preventing RIR shopping will become largely moot (but still > recommended). The perception then of anti-shopping provisions might then > be that it maintains stability, rather than penalizing any > RIR/LIR/region. > > Additional Observations about Fast vs Slow RIRs > > Fast-consuming RIRs will contribute more heavily towards the consumption > rate. In turn, these RIRs will be the largest component of the > projections of IED. > > Low-consuming RIRs will have less impact on IED. However, the low rate > means that these RIRs will have *greater* proportional accuracy when it > comes to knowing how much space they need between present time and IED. > (This is because, the uncertainty on allocation needs, will be the > result of multiplying the uncertainty on IED date, by the rate of > consumption. Low-consuming LIRs, will have less uncertainty on their > penultimate allocation.) > > The uncertainty on exact date of IED, is expected to be largely > invariant across RIRs. > > Any changes to individual RIR allocation trends, after the "pie split" > date, are not expected to exceed the individual RIR's own uncertainty at > "pie split" date. In other words, the accuracy of each RIR's IED is > expected to increase over time, and to continue to fall within the range > of the original upper and lower limits (based on rounding to /12) of the > RIR's allocation from IANA. > > 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. > From info at arin.net Wed Nov 7 17:33:53 2007 From: info at arin.net (Member Services) Date: Wed, 07 Nov 2007 17:33:53 -0500 Subject: Policy Proposal: Cooperative distribution of the end of the IPv4 free pool Message-ID: <47323D51.1070005@arin.net> 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: Cooperative distribution of the end of the IPv4 free pool Author: Tony Hain Proposal Version: 1.0 Submission Date: Oct-30-2007 Proposal type: new Policy term: permanent Policy summary: This policy will establish a process for RIR-to-RIR redistribution of the tail-end of the IPv4 pool, taking effect after the IANA Reserve is exhausted. Each redistribution Allocation will be triggered by the recipient RIR depleting its reserve to a 30 day supply, and will result in up to a 3 month supply being transferred from the RIR with the longest remaining time before it exhausts its own pool. Policy statement: At the point when any given RIR is within 30 days of depleting its remaining IPv4 pool, a survey will be taken of the other 4 to determine the remaining time before each of them exhausts their pool (including both member use and recent redistribution allocations to other RIRs). The one with the longest window before exhausting its pool will be designated as the source RIR. The recipient RIR will follow procedures for an LIR in the source RIR region to request a block that is expected to be sufficient for up to 3 months, but is no larger than 1/8th of the source RIR's remaining pool. At the point where no RIR can supply a block that is less than 1/8th of their remaining pool that will sustain the recipient RIR for 30 days, the recipient RIR will collect its requests each week, and forward those individual requests to the source RIR designated that week. Rationale: This policy will establish a mechanism for the Allocation of IPv4 address blocks between RIR's, but will not go into effect until the IANA pool has been depleted. It is really bizarre to watch the maneuvering as the global RIR community grapples with 'fairness' of distributing the last few IANA Reserve /8 blocks. On one level this just appears to be petty sibling rivalry, as people are bickering over who gets the last cookie and whimpering about 'fairness'. At the same time, each RIR is chartered to look after the interests of its membership so it is to be expected that they will each want to get as much as possible to meet the needs of their respective membership. Existing practice requires RIR's to acquire blocks from IANA, which leads to the current round of nonsense about optimal distribution of the remaining pool based on elaborate mathematical models. This globally submitted policy proposal attempts to resolve the issue by shifting to an RIR-to-RIR Allocation model after the IANA pool is depleted. This policy would effectively result in each RIR becoming a virtual LIR member of all of the other RIR's for the sole purpose of managing the tail-end of the IPv4 pool. Timetable for implementation: Before 1/1/2009 From info at arin.net Thu Nov 8 08:22:04 2007 From: info at arin.net (Member Services) Date: Thu, 08 Nov 2007 08:22:04 -0500 Subject: [ppml] Policy Proposal: Cooperative distribution of the end of the IPv4 free pool In-Reply-To: <47323D51.1070005@arin.net> References: <47323D51.1070005@arin.net> Message-ID: <47330D7C.8030209@arin.net> > The AC will assign shepherds in the near future. ARIN will provide the > names of the shepherds to the community via the PPML. The shepherds from the ARIN Advisory Council for this proposal are Leo Bicknell and Bill Darte. Regards, Member Services American Registry for Internet Numbers (ARIN) Member Services wrote: > 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: Cooperative distribution of the end of the IPv4 > free pool > > Author: Tony Hain > > Proposal Version: 1.0 > > Submission Date: Oct-30-2007 > > Proposal type: new > > Policy term: permanent > > Policy summary: > This policy will establish a process for RIR-to-RIR redistribution of > the tail-end of the IPv4 pool, taking effect after the IANA Reserve is > exhausted. Each redistribution Allocation will be triggered by the > recipient RIR depleting its reserve to a 30 day supply, and will result > in up to a 3 month supply being transferred from the RIR with the > longest remaining time before it exhausts its own pool. > > Policy statement: > At the point when any given RIR is within 30 days of depleting its > remaining IPv4 pool, a survey will be taken of the other 4 to determine > the remaining time before each of them exhausts their pool (including > both member use and recent redistribution allocations to other RIRs). > The one with the longest window before exhausting its pool will be > designated as the source RIR. The recipient RIR will follow procedures > for an LIR in the source RIR region to request a block that is expected > to be sufficient for up to 3 months, but is no larger than 1/8th of the > source RIR's remaining pool. At the point where no RIR can supply a > block that is less than 1/8th of their remaining pool that will sustain > the recipient RIR for 30 days, the recipient RIR will collect its > requests each week, and forward those individual requests to the source > RIR designated that week. > > Rationale: > This policy will establish a mechanism for the Allocation of IPv4 > address blocks between RIR's, but will not go into effect until the IANA > pool has been depleted. > > It is really bizarre to watch the maneuvering as the global RIR > community grapples with 'fairness' of distributing the last few IANA > Reserve /8 blocks. On one level this just appears to be petty sibling > rivalry, as people are bickering over who gets the last cookie and > whimpering about 'fairness'. At the same time, each RIR is chartered to > look after the interests of its membership so it is to be expected that > they will each want to get as much as possible to meet the needs of > their respective membership. > > Existing practice requires RIR's to acquire blocks from IANA, which > leads to the current round of nonsense about optimal distribution of the > remaining pool based on elaborate mathematical models. > > This globally submitted policy proposal attempts to resolve the issue by > shifting to an RIR-to-RIR Allocation model after the IANA pool is depleted. > > This policy would effectively result in each RIR becoming a virtual LIR > member of all of the other RIR's for the sole purpose of managing the > tail-end of the IPv4 pool. > > Timetable for implementation: Before 1/1/2009 > > _______________________________________________ > 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. > From info at arin.net Mon Nov 19 11:56:33 2007 From: info at arin.net (Member Services) Date: Mon, 19 Nov 2007 11:56:33 -0500 Subject: ARIN Mailing List Acceptable Use Policies (AUPs) Message-ID: <4741C041.6060500@arin.net> As a reminder to the community, ARIN enforces the Acceptable Use Policies (AUPs) to safeguard and facilitate open, constructive dialogue on its mailing lists. There are two Mailing List AUPs found in Section 9 of the Number Resource Policy Manual. This AUP is available on the ARIN website at: http://www.arin.net/policy/nrpm.html#nine1 Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Tue Nov 20 13:47:05 2007 From: info at arin.net (Member Services) Date: Tue, 20 Nov 2007 13:47:05 -0500 Subject: Policy Proposal: IPv6 Assignment Size Reduction - AC did not accept Message-ID: <47432BA9.9040506@arin.net> On 15 November 2007, the ARIN Advisory Council (AC) concluded its review of the proposed policy 'IPv6 Assignment Size Reduction' and did not accept it as a formal policy proposal. The AC provided the following explanation of their decision: "The reason we do not accept it is because there has not been any support on the Public Policy Mailing List." During the initial review period the AC may decide to: 1) Accept the proposal as a formal policy proposal as written. 2) Postpone their decision regarding the proposal until the next regularly scheduled AC meeting in order to work with the author. 3) Not accept the policy proposal. In the event that the AC decides not to accept the proposal, then the author may elect to use the petition process to advance the proposal. For petition details see the section called "Petition Process" in the ARIN Internet Resource Policy Evaluation Process which can be found at: http://www.arin.net/policy/irpep.html The deadline for the author to initiate a petition per the ARIN Internet Resource Policy Evaluation Process is 40 days prior to the meeting; the petition deadline for the ARIN XXI Public Policy Meeting is 23:59 EDT, 27 February 2008. If the author chooses not to petition or the petition is unsuccessful, then the proposed policy is closed. If a petition is successful, then the proposal will be numbered and posted for discussion and presented at ARIN's Public Policy Meeting. 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 From info at arin.net Tue Nov 20 13:51:05 2007 From: info at arin.net (Member Services) Date: Tue, 20 Nov 2007 13:51:05 -0500 Subject: Policy Proposal: globally-coordinated-RIR-pie-IPv4 - AC postponed decision Message-ID: <47432C99.90500@arin.net> On 15 November 2007, the ARIN Advisory Council (AC) postponed their decision regarding "globally-coordinated-RIR-pie-IPv4" in order for the shepherds to work with the author. The AC will review this proposal at their next regularly scheduled meeting. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/submission_archive.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: globally-coordinated-RIR-pie-IPv4 Author: Brian Dickson Proposal Version: 1 Submission Date: 26 October 2007 Proposal type: new Policy term: renewable Policy statement: This policy concerns the globally-coordinated allocations of IPv4 address space from IANA to the RIRs. The policy is intended to be compatible with 2007-23 (in its expected final form). The overview of the policy is: At the last reasonable time to do so, divide up the remaining IPv4 space based on currently projected use between that time and the date at which no more IPv4 space is available at any RIR for new allocations. Here is how the policy is to be implemented: 1) RIRs should provide up-to-date assignment projections for their respective regions, and provide up-to-date utilization on their current IANA-assigned block(s) from which assignments are made. 2) RIRs should provide an official projection on IANA Exhaustion Date (IED) to the community through their website, at their Policy Meetings and through any other effective means. 3) When any RIR requests a /8 from IANA, the current assignment projections for that RIR should be combined with the RIR's currently available IANA blocks (i.e. from which RIR assignments are made). This should be compared with the global available IANA unused space (for allocating to RIRs), the current projected usage rate of the RIR, and the current projected IED. If the RIR projection shows that the RIR would not expect to use up two /8 blocks before IED, the "Pie-splitting" event will be triggered. 4) Splitting the Pie - the following method will be used to determine the final IPv4 global IANA allocations to the RIRs: For each RIR, the following calculation will be done: (i) Determine from the current projection, the total allocations the RIR will make from present to IED (ii) Subtract from this, unallocated RIR space already received from ARIN (if any) (iii) Round the result to the nearest /12 (iv) Subtract from this amount, one /8 (to be set aside to satisfy the 2005-23 policy proposal for "End Policy for IANA IPv4 allocations to RIRs") (v) Allocate this amount to the RIR immediately. Every effort should be made to divide these allocations among RIRs in as aggregatable a fashion as possible. 5) The allocations made will result in just 5 * /8 being left in the IANA pool, which will trigger 2007-23. 6) This in turn, will result in the last 5 * /8's being allocate to the RIR's, one for each. Rationale: The objective of this policy is to ensure that the remaining IPv4 pool is distributed so as to provide each RIR with a quantity of IPv4 addresses that will last for an expected duration. The intent is for this duration to be as close to the same for each RIR as possible. By following the rules above, the "pie split" is done: - as late as possible - as fairly as possible - in a consistent manner for all RIRs - early enough that each RIR is guaranteed at least one /8 The final /8 allocations are done *after* this allocation, so that there can be no issue of fairness, with each RIR being guaranteed to get one of the final /8's at the same time. The "pie split" is timed so that no RIR will have so much (relative) IPv4 address space, as to expect to have IPv4 space after any other RIR has exhausted its own IPv4 space. By providing a "pie split" which is based on the same data as the IED projection, the following results occur: - there is no contention over the process by which the division of resources occur - all RIRs have the ability to project, well in advance of the "pie split", exactly when their own IPv4 space will be exhausted. It will happen at the IED date -- no sooner, no later. - No RIR "shopping" is likely to occur. Consequently, no inter-RIR "land grab" is likely to occur, and thus the projections for IED itself are likely to remain consistent, as will the per-RIR projections. - LIRs are likely to view the policy as neutral, and thus fair. - Because it removes the incentive for RIR shopping, the rules preventing RIR shopping will become largely moot (but still recommended). The perception then of anti-shopping provisions might then be that it maintains stability, rather than penalizing any RIR/LIR/region. Additional Observations about Fast vs Slow RIRs Fast-consuming RIRs will contribute more heavily towards the consumption rate. In turn, these RIRs will be the largest component of the projections of IED. Low-consuming RIRs will have less impact on IED. However, the low rate means that these RIRs will have *greater* proportional accuracy when it comes to knowing how much space they need between present time and IED. (This is because, the uncertainty on allocation needs, will be the result of multiplying the uncertainty on IED date, by the rate of consumption. Low-consuming LIRs, will have less uncertainty on their penultimate allocation.) The uncertainty on exact date of IED, is expected to be largely invariant across RIRs. Any changes to individual RIR allocation trends, after the "pie split" date, are not expected to exceed the individual RIR's own uncertainty at "pie split" date. In other words, the accuracy of each RIR's IED is expected to increase over time, and to continue to fall within the range of the original upper and lower limits (based on rounding to /12) of the RIR's allocation from IANA. Timetable for implementation: immediate From info at arin.net Tue Nov 20 13:51:29 2007 From: info at arin.net (Member Services) Date: Tue, 20 Nov 2007 13:51:29 -0500 Subject: Policy Proposal: 200-reduction-6.5.1.1.d - AC postponed decision Message-ID: <47432CB1.4090301@arin.net> On 15 November 2007, the ARIN Advisory Council (AC) postponed their decision regarding "200-reduction-6.5.1.1.d" in order for the shepherds to work with the author. The AC will review this proposal at their next regularly scheduled meeting. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/submission_archive.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: 200-reduction-6.5.1.1.d Author: Brian Dickson Proposal Version: 1 Submission Date: Oct 18, 2007 Proposal type: modify Policy term: permanent Policy statement: In 6.5.1.1 d), where 2007-25 proposes: "be an existing, known ISP in the ARIN region or have a plan for making at least 200 end-site assignments to other organizations within 5 years." replace with" "be an existing, known ISP in the ARIN region or have a plan for making at least 20 end-site assignments to other organizations, or for providing IPv6 transit to one or more IPv6 PI blocks belonging to other organizations, within 5 years." Rationale: The purpose of the text is to establish reasonable ways for an ISP to demonstrate that it is in fact an ISP. Any of the above listed conditions satisfy that need, and the intent is to avoid having the text of the policy prevent any legitimate ISP from receiving an initial IPv6 allocation. It does lower the bar, but in a justifiable fashion. It is not necessary for an ISP to have lots of PA assignments. It is necessary for an ISP to be announcing PA *or* PI blocks to the internet, and relaxing the criteria to recognize both possibilities jointly, makes the policy reflect the actual realities for any number of large regional ISPs, who may have sold off portions of their business but who still operate significant infrastructure. Timetable for implementation: Immediate From info at arin.net Tue Nov 20 13:51:58 2007 From: info at arin.net (Member Services) Date: Tue, 20 Nov 2007 13:51:58 -0500 Subject: Policy Proposal 2007-27: Cooperative distribution of the end of the IPv4 free pool Message-ID: <47432CCE.5050106@arin.net> On 15 November 2007, the ARIN Advisory Council (AC) concluded their initial review of "Cooperative distribution of the end of the IPv4 free pool" and accepted it as a formal policy proposal for discussion by the community. The proposal is designated Policy Proposal 2007-27: Cooperative distribution of the end of the IPv4 free pool. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2007_27.html All persons in the community are encouraged to discuss Policy Proposal 2007-27 prior to it being presented at the ARIN XXI Public Policy Meeting in April 2008. Both the discussion on the Public Policy Mailing List and at the Public Policy Meeting will be used to determine the community consensus regarding this policy proposal. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html ARIN's Policy Proposal Archive can be found at: http://www.arin.net/policy/proposals/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-27 Cooperative distribution of the end of the IPv4 free pool Author: Tony Hain Proposal type: new Policy term: permanent Policy summary: This policy will establish a process for RIR-to-RIR redistribution of the tail-end of the IPv4 pool, taking effect after the IANA Reserve is exhausted. Each redistribution Allocation will be triggered by the recipient RIR depleting its reserve to a 30 day supply, and will result in up to a 3 month supply being transferred from the RIR with the longest remaining time before it exhausts its own pool. Policy statement: At the point when any given RIR is within 30 days of depleting its remaining IPv4 pool, a survey will be taken of the other 4 to determine the remaining time before each of them exhausts their pool (including both member use and recent redistribution allocations to other RIRs). The one with the longest window before exhausting its pool will be designated as the source RIR. The recipient RIR will follow procedures for an LIR in the source RIR region to request a block that is expected to be sufficient for up to 3 months, but is no larger than 1/8th of the source RIR's remaining pool. At the point where no RIR can supply a block that is less than 1/8th of their remaining pool that will sustain the recipient RIR for 30 days, the recipient RIR will collect its requests each week, and forward those individual requests to the source RIR designated that week. Rationale: This policy will establish a mechanism for the Allocation of IPv4 address blocks between RIR's, but will not go into effect until the IANA pool has been depleted. It is really bizarre to watch the maneuvering as the global RIR community grapples with 'fairness' of distributing the last few IANA Reserve /8 blocks. On one level this just appears to be petty sibling rivalry, as people are bickering over who gets the last cookie and whimpering about 'fairness'. At the same time, each RIR is chartered to look after the interests of its membership so it is to be expected that they will each want to get as much as possible to meet the needs of their respective membership. Existing practice requires RIR's to acquire blocks from IANA, which leads to the current round of nonsense about optimal distribution of the remaining pool based on elaborate mathematical models. This globally submitted policy proposal attempts to resolve the issue by shifting to an RIR-to-RIR Allocation model after the IANA pool is depleted. This policy would effectively result in each RIR becoming a virtual LIR member of all of the other RIR's for the sole purpose of managing the tail-end of the IPv4 pool. Timetable for implementation: Before 1/1/2009