From rich at nic.umass.edu Thu Sep 1 10:00:07 2005 From: rich at nic.umass.edu (Rich Emmings) Date: Thu, 1 Sep 2005 10:00:07 -0400 (EDT) Subject: [ppml] Proposed Policy: Proposal to amend ARIN IPv6 assignment and utilisation requirement In-Reply-To: <431318F9.8060604@arin.net> References: <431318F9.8060604@arin.net> Message-ID: Opposed. Does this proposal help with a short term problem, or promote the adoption of IPv6? No. If utilization becomes a problem, space yet to be allocated outside of 2000::/3 can be allocated in smaller blocks in the future, and still leave enough. Done this way, justifications for the proposal in reference to early adopters vs latecomers are mitigated. Large scale introduction of /56 addresses may also increase the global routing table size. End site assignment of a /48 is a recommendation and nothing prohibits the assignment of a /56 downstream where appropriate. The advocacy for the number of average end-site nets can probably be argued down to the next nibble or bits forever. Changes slow implementation. That some of these changes are necessary doesn't alter the impact. At this time, this is an unnecessary change, so let's skip it and move on to implementation issues. On Mon, 29 Aug 2005, Member Services wrote: > ARIN received the following proposed policy. In accordance with the ARIN > Internet Resource Policy Evaluation Process, the proposal is being > posted to the ARIN Public Policy Mailing List and being placed on ARIN's > website. > > The ARIN Advisory Council (AC) will review the proposal and within ten > working days may decide to: > 1) Support the proposal as is, > 2) Work with the author to clarify, divide or combine one or more > policy proposals, or > 3) Not support the policy proposal. > > If the AC supports the proposal or reaches an agreement to work with the > author, then the proposal will be posted as a formal policy proposal to > the Public Policy Mailing List and it will be presented at the Public > Policy Meeting. If the AC does not support the proposal, then the author > may elect to use the petition process to advance the proposal. If the > author elects not to petition or the petition fails, then the proposed > policy will be considered closed. > > 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/index.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > ### * ### > > Policy Proposal Name: Proposal to amend ARIN IPv6 assignment and > utilisation requirement (Section 6 of ARIN Number Resource Policy Manual) > > Author: Thomas Narten and Lea Roberts > > [Balance deleted] From Lee.Howard at stanleyassociates.com Thu Sep 1 10:26:25 2005 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Thu, 1 Sep 2005 10:26:25 -0400 Subject: [ppml] Proposed Policy: Proposal to amend ARIN IPv6 assignment and utilisation requirement Message-ID: <3F05EE24A82C0B42811178EFB8820C3F4654E1@AX-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Rich Emmings > Sent: Thursday, September 01, 2005 10:00 AM > To: Member Services > Cc: ppml at arin.net > Subject: Re: [ppml] Proposed Policy: Proposal to amend ARIN > IPv6 assignment and utilisation requirement > > Opposed. > > Does this proposal help with a short term problem, or promote > the adoption of IPv6? Since the potential problem is long term, we shouldn't do anything about it? > Large scale introduction of /56 addresses may also increase > the global routing table size. How? It might increase your local routing table size, but ISPs (LIRs) will still aggregate at their borders, unless leaking is required, and even then, a /56 doesn't take up more router slots than a /48. > End site assignment of a /48 is a recommendation and nothing > prohibits the assignment of a /56 downstream where appropriate. http://www.arin.net/policy/nrpm.html#six54 : -- 6.5.4. Assignment LIRs must make IPv6 assignments in accordance with the following provisions. 6.5.4.1. Assignment address space size Assignments are to be made in accordance with the existing guidelines (RFC3177,RIRs-on-48), which are summarized here as: - /48 in the general case, except for very large subscribers -- That's not squishy language. It is exactly the language used in RFC3177, "IAB/IESG Recommendations on IPv6 Allocations to Sites," which is an informational RFC, but it looks to me like the RIRs took the recommendations and made them policy. > The advocacy for the number of average end-site nets can > probably be argued > down to the next nibble or bits forever. So you advocate setting policy based on the .001% case? No network left behind? > Changes slow implementation. That some of these changes are > necessary doesn't alter the impact. > At this time, this is an unnecessary change, so let's skip it > and move on to implementation issues. I'm in favor of building right the first time, and in assigning appropriate levels of resources. Lee > On Mon, 29 Aug 2005, Member Services wrote: > > > ARIN received the following proposed policy. In accordance > with the ARIN > > Internet Resource Policy Evaluation Process, the proposal is being > > posted to the ARIN Public Policy Mailing List and being > placed on ARIN's > > website. > > > > The ARIN Advisory Council (AC) will review the proposal and > within ten > > working days may decide to: > > 1) Support the proposal as is, > > 2) Work with the author to clarify, divide or combine one or more > > policy proposals, or > > 3) Not support the policy proposal. > > > > If the AC supports the proposal or reaches an agreement to > work with the > > author, then the proposal will be posted as a formal policy > proposal to > > the Public Policy Mailing List and it will be presented at > the Public > > Policy Meeting. If the AC does not support the proposal, > then the author > > may elect to use the petition process to advance the > proposal. If the > > author elects not to petition or the petition fails, then > the proposed > > policy will be considered closed. > > > > 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/index.html > > > > Regards, > > > > Member Services > > American Registry for Internet Numbers (ARIN) > > > > ### * ### > > > > Policy Proposal Name: Proposal to amend ARIN IPv6 assignment and > > utilisation requirement (Section 6 of ARIN Number Resource > Policy Manual) > > > > Author: Thomas Narten and Lea Roberts > > > > [Balance deleted] > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From memsvcs at arin.net Thu Sep 1 15:54:41 2005 From: memsvcs at arin.net (Member Services) Date: Thu, 01 Sep 2005 15:54:41 -0400 Subject: [ppml] Policy Proposal 2005-7: Rationalize Multi-Homing Definition and Requirement Message-ID: <43175C81.8010005@arin.net> On August 31, 2005, the ARIN Advisory Council (AC) concluded its review of proposed policy "Rationalize Multi-Homing Definition and Requirement" and agreed to forward it as a formal proposal for discussion by the community. This proposal is designated 2005-7: Rationalize Multi-Homing Definition and Requirement. The policy proposal text is below and can be found at: http://www.arin.net/policy/proposals/2005_7.html All persons in the community are encouraged to discuss Policy Proposal 2005-7 in the weeks leading to the ARIN Public Policy Meeting in Los Angeles, CA, scheduled for October 26-27. Both the discussion on the PPML 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/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2005-7: Rationalize Multi-Homing Definition and Requirement Author: Robert Seastrom Policy statement: In existing policy 4.2.2.2, replace the phrase "multi-homed organizations must:" with the phrase "organizations applying under the multi-homed policy must:" In existing policy 4.2.2.2.2, replace "Provide information showing that the requested IP address space will be utilized within three months." with "Provide information showing that the requested IP address space will be utilized within three months and demonstrating an intent to announce the requested space in a multi-homed fasion." Rationale: Presently, organizations wishing to apply for their first address space under the multi-homed policy must demonstrate that they have ALREADY announced a DIFFERENT address block via multi-homing, while simultaneously promising to renumber out of that same block. This creates needless make-work for ISPs which are planning to multi-home, related to old resources which they're already trying to get out of. Likewise, it creates needless work for both of their upstream providers, who have to temporarily announce a prefix which DOESN'T NEED to be multi-homed, solely to demonstrate to ARIN analysts that the applying ISP is multi-homed. However, this same criterion can be demonstrated just as effectively by the applying ISP showing the analyst contracts with multiple ISPs under which the newly-applied-for block WILL BE multi-homed, and this more accurately reflects the intent of the original policy, while removing needless make-work at a time when the applicant is surely already quite busy with the real requirements of their change-over. From memsvcs at arin.net Thu Sep 1 15:56:28 2005 From: memsvcs at arin.net (Member Services) Date: Thu, 01 Sep 2005 15:56:28 -0400 Subject: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and, utilisation requirement Message-ID: <43175CEC.9010104@arin.net> On August 31, 2005, the ARIN Advisory Council (AC) concluded its review of proposed policy "Proposal to amend ARIN IPv6 assignment and utilisation requirement" and agreed to forward it as a formal proposal for discussion by the community. This proposal is designated 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement (Section 6 of ARIN Number Resource Policy Manual). The policy proposal text is below and can be found at: http://www.arin.net/policy/proposals/2005_8.html All persons in the community are encouraged to discuss Policy Proposal 2005-8 in the weeks leading to the ARIN Public Policy Meeting in Los Angeles, CA, scheduled for October 26-27. Both the discussion on the PPML 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/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement Author: Thomas Narten and Lea Roberts Policy statement: It is proposed to make the following changes to the existing ARIN IPv6 policy: 1. Define an additional end site assignment size of /56. This /56 assignment should be considered the general case, intended for small office, household, and personal networks, and other small and medium-sized deployments where the number of potential subnets exceeds 1, but is not expected to exceed 256. 2. Amend the existing policy regarding /48 end-site assignments to refer specifically to assignments to large enterprise and corporate end-site environments where there is a requirement for more than 255 subnets at the end site. 3. Amend the evaluation threshold calculation to be based on a default end site assignment size of a /56. Further end-site assignment information should be provided to ARIN in order to use a different average end-site assignment size for HD-ratio calculation purposes. Rationale: The key benefit of IPv6 is its large address space, and a fundamental assumption motivating its adoption is that with IPv6, sufficient address space will always be available to ensure that users can obtain sufficent public address space for their needs. Projections for IPv6 address consumption over the next 50-100 years indicate that there are scenarios (depending on one's assumptions) in which a signficant percentage of the total IPv6 address space could be handed out, raising the possibility that address allocation policies will then need to be revised to become significantly more conservative to ensure that the IPv6 address space does not become exhausted. Given the IPv4 experience, in which early adopters were able to acquire large amounts of address space easily, but later adopters were not, and the resultant problems this has caused, it would be preferable to take steps now to signficantly reduce the likelyhood of ever needing to make such a change, especially if changes can be made with minimal impact. The RIR communities adopted address allocation policies in 2002 in which the default assignment to end sites was assumed to be a /48 in many cases. For SOHO users (e.g., home users and small businesses), being given enough address space to number 65,536 subnets seems excessive given their anticipated needs. Changing the default assignment size to a /56 allows for numbering 256 subnets, still a large number. Making such a change would save roughly two orders of magnitude of address space. That is, for any projection made assuming a /48 assignment, assigning /56s instead would result in roughly 100 times less total consumption. The goal of this policy proposal is not to make it impossible for end sites to obtain a /48. Rather, it is intended to make the default assignment size a /56 in the vast number of cases where a /48 seems profligate. In those cases where the end site can argue that it has a need for more than 256 subnets, a /48 should be given out. Background information: "Issues Related to the Management of IPv6 Address Space", by Thomas Narten. http://www.ietf.org/internet-drafts/draft-narten-iana-rir-ipv6-considerations-00.txt Similar policy proposal submitted to APNIC (includes detailed background and pointers to more background information than is included here). http://www.apnic.net/docs/policy/discussions/prop-031-v001.txt State of related discussion in other RIRs: See section "Situation in other RIRs" in http://www.apnic.net/docs/policy/discussions/prop-031-v001.txt IETF revisitation of RFC 3177 "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", the document in which the case for assigning /48s was made. http://www.ietf.org/internet-drafts/draft-narten-ipv6-3177bis-48boundary-00.txt (note: this document was adopted as a WG item by the IPv6 WG at IETF 63 in August.) From memsvcs at arin.net Thu Sep 1 15:57:51 2005 From: memsvcs at arin.net (Member Services) Date: Thu, 01 Sep 2005 15:57:51 -0400 Subject: [ppml] Proposed Policy: IPv6 Direct assignments to end sites Message-ID: <43175D3F.7090407@arin.net> The ARIN Advisory Council conducted a meeting on August 31, 2005, to consider the proposed policy "IPv6 Direct assignments to end sites". The AC decided that there was enough similarity between this proposal and policy Proposal 2005-1 that it will work with both authors to merge these proposals into Policy Proposal 2005-1. The AC expects to complete this work with the authors no later than September 16, 2005, at which time the revised policy language for Policy Proposal 2005-1 will be published to the PPML for discussion by the community. The original proposed policy text is below and can be found at: http://lists.arin.net/pipermail/ppml/2005-August/003985.html Regards, Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal Name: IPv6 Direct assignments to end sites Author: Kevin Loch Policy Statement: Changes to NRPM section 6: add new section 6.5.8: 6.5.8. Direct assignments to end sites. 6.5.8.1. To qualify for a direct end site assignment, an organization must: a) not be an LIR; b) be an end site; c) be currently multi-homed using IPv6 to two or more separate LIR's. native connections or statically configured tunnels may be used to satisfy this requirement. d) The prefix(es) used by the end site to demonstrate multihoming must be visible in the ARIN whois databse or via rwhois as being assigned to the requesting organization. 6.5.8.2. Direct assignment size to end sites Organizations that meet the direct end site assignment criteria are eligible to receive a direct assignment of /48 6.5.8.3. Subsequent direct assignments to end sites Only one direct assignment may be made to an end site organization. End sites that require more than 65536 subnets should request space from an LIR or consider becoming an LIR. 6.5.8.4. Migration from end site to LIR A direct end site assignment shall not disqualify an organization from becoming an LIR and ceasing to be an end site if it otherwise meets the requirements for an initial allocation. Organizations receiving an LIR allocation must renumber into that allocation and return any direct assignments within 1 year. Micro allocations made under section 6.10 are not subject to this requirement. An LIR allocation shall disqualify an organization from receiving a direct end site assignment unless it agrees to return all LIR allocations within 1 year. Micro allocations made under section 6.10 are not subject to this requirement. Rationale: The lack of provider independent direct assignments is a significant impediment to adoption of IPv6 by enterprises and large content sites. This policy proposal defines clear verifiable requirements for receiving a direct assignment. Current IPv6 multi-homing was chosen as the key requirement for the following reasons: a) it is reasonable to expect that those reqesting provider independence would be connecting to two or more providers. b) the requirement of demonstrating current multi-homing will promote active deployment of IPv6 by those seeking direct assignments. It is possible that future technology developments will render this policy unnecessary. At this time there are no viable alternatives for IPv6 provider independence, other than becoming an LIR. It is likely that this will help conserve IPv6 address space as most organizations requiring provider independence could easily qualify for an LIR allocation under current policy. Allowing them to apply for the more appropriate /48 is responsible resource management. This policy can easily be adapted to increase requirements for direct assignments if future conditions warrant. For example, the multihoming demonstration requirement could be increased to three or four separate LIR's. Additional verification of active current multihoming could be used. Or, as native connectivity becomes widespread the option of tunnel based connections for justification could be removed. It is extremely unlikely that this will result in a "land rush" of direct assignments. The requirements in this policy require more effort than the current requirements for a /32. Alternatively, a large number of applications would be a good sign of sincere IPv6 deployment due to the requirement to be currently multihomed. Timetable for implementation: Immediately From gih at apnic.net Thu Sep 1 19:29:37 2005 From: gih at apnic.net (Geoff Huston) Date: Fri, 02 Sep 2005 09:29:37 +1000 Subject: [ppml] Proposed Policy: Proposal to amend ARIN IPv6 assignment and utilisation requirement In-Reply-To: References: <431318F9.8060604@arin.net> Message-ID: <6.2.0.14.2.20050902092323.024b2150@kahuna.telstra.net> At 12:00 AM 2/09/2005, Rich Emmings wrote: >Opposed. > >Does this proposal help with a short term problem, or promote the adoption >of IPv6? > >No. > >If utilization becomes a problem, space yet to be allocated outside of >2000::/3 can be allocated in smaller blocks in the future, and still leave >enough. Done this way, justifications for the proposal in reference to >early adopters vs latecomers are mitigated. If the current address plan has risks of premature exhaustion, then the consequent question is whether these risks should be addressed now or later. One approach is to adopt a "wait and see" attitude, and defer consideration until more data is available. This viewpoint is expressed in RFC3177: "We are highly confident in the validity of this analysis, based on experience with IPv4 and several other address spaces, and on extremely ambitious scaling goals for the Internet amounting to an 80 bit address space *per person*. Even so, being acutely aware of the history of under-estimating demand, the IETF has reserved more than 85% of the address space (i.e., the bulk of the space not under the 001 Global Unicast Address prefix). Therefore, if the analysis does one day turn out to be wrong, our successors will still have the option of imposing much more restrictive allocation policies on the remaining 85%. However, we must stress that vendors should not encode any of the boundaries discussed here either in software nor hardware. Under that assumption, should we ever have to use the remaining 85% of the address space, such a migration may not be devoid of pain, but it should be far less disruptive than deployment of a new version of IP." [RFC 3177] An alternative way of expressing this perspective is that it appears to be premature to consider changes to the IPv6 address plan when we have so little experience with deployment of IPv6. It would appear that we are not qualified to make such decision and leave them to more qualified individuals. Who would they be? From this perspective they would be the network engineers of the future who would have had 10-20 years of IPv6 operational experience. Lets look at this assertion in a little more detail. Now if the consumption analysis in RFC3177 is indeed flawed, and uptake is larger than has been anticipated in the current IPv6 address plan, then yes, there will still be large pools of unallocated address space available, and yes, it will be possible, in theory at any rate, to use a different addressing plan on the remaining space which targets a higher utilization rate. However the installed base of IPv6 will also be extremely large at this point. Indeed it will be so large that the problem of inertial mass and potential gross inequities in distribution structures will effectively imply that any changes will be extremely tough politically. It could be argued that we have already lived through a similar transition in IPv4 in the change from class-based addressing to one of classless addressing plus Network Address Translators. The legacy of this transition is uncomfortable, with later adopters pointing to the somewhat liberal address holdings of the early adopters and asking why they have to bear the brunt of the cost and effort to achieve very high address utilization rates while the early adopters are still able to deploy relatively simple, but somewhat more extravagant addressing schemes across their networks. When to consider such a change to the address plan is very much a public policy topic. While there is a temptation to leave well alone, from a public policy perspective we stand the risk of, yet again, visibly creating an early adopter reward and a corresponding late adopter set of barriers and penalties. I suspect that IP has already exhausted any tolerance that may have been enjoyed in the past on this type of behaviour and there is a strong impetus on the part of many developing populous economies not to see such a precise rerun of what they would term previous mistakes. This is not an abstract concept but one where we are already seeing proposals from the ITU-T to establish an alternative address distribution system that is based around this particular concern of re-creating a framework that has already established early adopter rewards and late adopter penalties in IPv4, and is looking to repeat this same inequitous pattern in IPv6.. In other words it is possible to put forward the proposition that this is a premature discussion, but others, for equally valid reasons, see it as being timely, while others see this as an urgent priority. There is a case to be made that we should study the evolution of address policies in the history of IPv4 and be careful to avoid a needless repetition of earlier mistakes. It would appear to be prudent, and indeed "fairer" to plan for success rather than failure, and plan for extensive, indeed ubiquitous deployment of IPv6 for an extended period of time. In such a scenario there is little room for structural inequities in the address distribution model, and that at all times all players should be positioned evenly with respect to access to addresses. Consequently there would be little room to adjust the address plan parameters on the fly and we should exercise some care to ensure that the address plan structure we adopt at the outset has sufficient room to accommodate future requirements on a similar, if not identical, basis. From this perspective the time for consideration of the address plan and its associated parameters is now, rather than deferring the matter to some unspecified future time. The alternative is that the installed base of IPv6 will consume very little address space in the coming decades, in which case the entire topic would be irrelevant! In other words this topic is predicated on the assumption that in some 50 or 100 years hence we will still be using IP as the base technology for a global communications enterprise. regards, Geoff Huston From Lee.Howard at stanleyassociates.com Fri Sep 2 14:00:03 2005 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Fri, 2 Sep 2005 14:00:03 -0400 Subject: [ppml] Alternative address distribution systems (was Proposal 2005-8) Message-ID: <3F05EE24A82C0B42811178EFB8820C3F465734@AX-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Geoff Huston > Sent: Thursday, September 01, 2005 7:30 PM > To: Rich Emmings > Cc: ppml at arin.net > Subject: Re: [ppml] Proposed Policy: Proposal to amend ARIN > IPv6 assignment and utilisation requirement > > At 12:00 AM 2/09/2005, Rich Emmings wrote: > >Opposed. > > > When to consider such a change to the address plan is very > much a public > policy topic. While there is a temptation to leave well alone, from a > public policy perspective we stand the risk of, yet again, > visibly creating > an early adopter reward and a corresponding late adopter set > of barriers > and penalties. I suspect that IP has already exhausted any > tolerance that > may have been enjoyed in the past on this type of behaviour > and there is a > strong impetus on the part of many developing populous > economies not to see > such a precise rerun of what they would term previous > mistakes. This is not > an abstract concept but one where we are already seeing > proposals from the > ITU-T to establish an alternative address distribution system > that is based > around this particular concern of re-creating a framework > that has already > established early adopter rewards and late adopter penalties > in IPv4, and > is looking to repeat this same inequitous pattern in IPv6.. I'm glad somebody brought this up. There's been no discussion in this neighborhood of alternative address distribution systems. Kind of odd, since there's been lots of talk about it in other places. For instance: http://www.circleid.com/channel/index/C0_1_1/ http://www.circleid.com/channel/index/C0_8_1/ http://www.itu.int/ITU-T/tsb-director/itut-wsis/files/zhao-netgov01.doc http://www.wgig.org/docs/WGIGREPORT.pdf What would people here think of allocating part of IPv6 to alternative registries? Would it make a difference in your opinion if the registries were national? Would it make a difference in your opinion if the ITU were coordinating? Lee > Geoff Huston From jim at tgasolutions.com Sat Sep 3 00:00:37 2005 From: jim at tgasolutions.com (Jim McBurnett) Date: Sat, 3 Sep 2005 00:00:37 -0400 Subject: [ppml] Policy Proposal 2005-7: Rationalize Multi-Homing Definitionand Requirement Message-ID: <5432D045DAFD8040BCE549749263BD0032E48E@testsystem2.tga.local> Sorry all for the late question. Am I to understand that this policy should prevent a requesting end user from getting X space from an ISP to multi-home just so they can prove they are multi-homed in order to request ARIN direct IP space? Thanks, Jim -----Original Message----- From: Member Services [mailto:memsvcs at arin.net] Sent: Thursday, September 01, 2005 3:55 PM To: ppml at arin.net Subject: [ppml] Policy Proposal 2005-7: Rationalize Multi-Homing Definitionand Requirement On August 31, 2005, the ARIN Advisory Council (AC) concluded its review of proposed policy "Rationalize Multi-Homing Definition and Requirement" and agreed to forward it as a formal proposal for discussion by the community. This proposal is designated 2005-7: Rationalize Multi-Homing Definition and Requirement. The policy proposal text is below and can be found at: http://www.arin.net/policy/proposals/2005_7.html All persons in the community are encouraged to discuss Policy Proposal 2005-7 in the weeks leading to the ARIN Public Policy Meeting in Los Angeles, CA, scheduled for October 26-27. Both the discussion on the PPML 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/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2005-7: Rationalize Multi-Homing Definition and Requirement Author: Robert Seastrom Policy statement: In existing policy 4.2.2.2, replace the phrase "multi-homed organizations must:" with the phrase "organizations applying under the multi-homed policy must:" In existing policy 4.2.2.2.2, replace "Provide information showing that the requested IP address space will be utilized within three months." with "Provide information showing that the requested IP address space will be utilized within three months and demonstrating an intent to announce the requested space in a multi-homed fasion." Rationale: Presently, organizations wishing to apply for their first address space under the multi-homed policy must demonstrate that they have ALREADY announced a DIFFERENT address block via multi-homing, while simultaneously promising to renumber out of that same block. This creates needless make-work for ISPs which are planning to multi-home, related to old resources which they're already trying to get out of. Likewise, it creates needless work for both of their upstream providers, who have to temporarily announce a prefix which DOESN'T NEED to be multi-homed, solely to demonstrate to ARIN analysts that the applying ISP is multi-homed. However, this same criterion can be demonstrated just as effectively by the applying ISP showing the analyst contracts with multiple ISPs under which the newly-applied-for block WILL BE multi-homed, and this more accurately reflects the intent of the original policy, while removing needless make-work at a time when the applicant is surely already quite busy with the real requirements of their change-over. _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From Michael.Dillon at btradianz.com Mon Sep 5 11:50:04 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Mon, 5 Sep 2005 16:50:04 +0100 Subject: [ppml] Alternative address distribution systems (was Proposal 2005-8) In-Reply-To: <3F05EE24A82C0B42811178EFB8820C3F465734@AX-S-EX-1.stanleyassociates.com> Message-ID: > What would people here think of allocating part of IPv6 to > alternative registries? Would it make a difference in your > opinion if the registries were national? Would it make a > difference in your opinion if the ITU were coordinating? I think that it is an excellent idea to allocate part of IPv6 to an alternative registry. However, I am opposed to doing this through political organizations such as the ITU or national governments. I think it should be done scientifically but this does mean that we need to wait until researchers can scientifically analyze the distribution of IPv6 address needs throughout the world for the next 50 years or so. What would help is for the RIR community to define the kind of research questions that need to be answered in order to make intelligent plans for IPv6 allocation. Those answers may show that that an alternate geographical allocation scheme is needed, or they may show that current allocation schemes are sufficient, or they may show that some modifications to current allocation schemes will better meet the needs of the entire planet in a fair and balanced way. We don't know the answers to these questions. This create the vacuum in which political solutions thrive. However, it is possible to get answers to many of these questions before we NEED to decide on alternative registry schemes. The prudent course of action is to encourage and support this research and to defer the decisions as to the details of any alternative registry scheme. --Michael Dillon From jim at tgasolutions.com Mon Sep 5 19:27:23 2005 From: jim at tgasolutions.com (Jim McBurnett) Date: Mon, 5 Sep 2005 19:27:23 -0400 Subject: [ppml] Policy Proposal 2005-7: Rationalize Multi-Homing Definitionand Requirement Message-ID: <5432D045DAFD8040BCE549749263BD0032E4A7@testsystem2.tga.local> Interesting... I called the helpdesk a little while back and asked for a multi-homing block for a customer that was about to dump their primary carrier and become multi-homed and was denied. I was told the denial was because the customer was not currently multi-homed and at face value could not justify a /22. So under this policy, I believe the customer would have been approved. With HIPPA, Sarbox, and the financial equivilent, our customers are moving to multi-homing. Most want a /23 or /24, and from my experience I have seen 1 to 2 week delays in getting IP's from some ISPs. This may really help the SMB market that wants to multi-home. Thanks, Jim -----Original Message----- From: Robert E.Seastrom [mailto:rs at seastrom.com] Sent: Saturday, September 03, 2005 9:52 AM To: Jim McBurnett Cc: Member Services; ppml at arin.net Subject: Re: [ppml] Policy Proposal 2005-7: Rationalize Multi-Homing Definitionand Requirement "Jim McBurnett" writes: > Sorry all for the late question. You're not late at all - 2005-7 is newly released and this is the first public comment I've made on it. > Am I to understand that this policy should prevent a requesting end > user from getting X space from an ISP to multi-home just so they can > prove they are multi-homed in order to request ARIN direct IP space? It should prevent the requester and their ARIN analyst from having to go through the intricate dance currently required to get PI space from ARIN for multihoming purposes. The intent is to harmonize the requirements for getting PI space for multihoming purposes with the requirements for getting an ASN, in the interests of eliminating needless extra steps (principally benefitting the requesting end user, but I'm sure the ARIN analysts won't complain about eliminating the extra steps). We don't, for instance, make people who wish to multihome "borrow" an ASN from some other organization and demonstrate that they have circuits in place - simply providing contracts or verification from two or more upstream ISPs is deemed sufficient. Nothing in 2005-7 is meant to be construed to prevent a requesting end user from getting delegated space from his ISP for the purposes of multihoming if that is how they wish to proceed. Those who require a block of address space that is large enough that it would represent a hardship to their ISP probably already qualify for space directly from ARIN under another existing policy anyway (for instance, 4.2.1.6 - Immediate Need). > Thanks, > Jim Hope this has been of some clarification. Best, ---Rob > > > -----Original Message----- > From: Member Services [mailto:memsvcs at arin.net] > Sent: Thursday, September 01, 2005 3:55 PM > To: ppml at arin.net > Subject: [ppml] Policy Proposal 2005-7: Rationalize Multi-Homing > Definitionand Requirement > > On August 31, 2005, the ARIN Advisory Council (AC) concluded its > review of proposed policy "Rationalize Multi-Homing Definition and Requirement" > and agreed to forward it as a formal proposal for discussion by the > community. This proposal is designated 2005-7: Rationalize > Multi-Homing Definition and Requirement. The policy proposal text is > below and can be found at: > http://www.arin.net/policy/proposals/2005_7.html > > All persons in the community are encouraged to discuss Policy Proposal > 2005-7 in the weeks leading to the ARIN Public Policy Meeting in Los > Angeles, CA, scheduled for October 26-27. Both the discussion on the > PPML 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/proposal_archive.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > ### * ### > > Policy Proposal 2005-7: Rationalize Multi-Homing Definition and > Requirement > > Author: Robert Seastrom > > Policy statement: In existing policy 4.2.2.2, replace the phrase > "multi-homed organizations must:" with the phrase "organizations > applying under the multi-homed policy must:" In existing policy > 4.2.2.2.2, replace "Provide information showing that the requested > IP address space will be utilized within three months." with > "Provide information showing that the requested IP address space > will be utilized within three months and demonstrating an intent > to > announce the requested space in a multi-homed fasion." > > Rationale: Presently, organizations wishing to apply for their first > address space under the multi-homed policy must demonstrate that > they have ALREADY announced a DIFFERENT address block via > multi-homing, while simultaneously promising to renumber out of > that same block. This creates needless make-work for ISPs which > are > planning to multi-home, related to old resources which they're > already trying to get out of. Likewise, it creates needless work > for both of their upstream providers, who have to temporarily > announce a prefix which DOESN'T NEED to be multi-homed, solely to > demonstrate to ARIN analysts that the applying ISP is multi-homed. > However, this same criterion can be demonstrated just as > effectively by the applying ISP showing the analyst contracts with > multiple ISPs under which the newly-applied-for block WILL BE > multi-homed, and this more accurately reflects the intent of the > original policy, while removing needless make-work at a time when > the applicant is surely already quite busy with the real > requirements of their change-over. > > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From memsvcs at arin.net Wed Sep 7 19:06:30 2005 From: memsvcs at arin.net (Member Services) Date: Wed, 7 Sep 2005 19:06:30 -0400 Subject: [ppml] NRPM version 2005.1 - New Policy Implementations Message-ID: <20050907230639.EC7B81FF2B@mercury.arin.net> On June 16, 2005, the ARIN Board of Trustees, based on the recommendations of the Advisory Council and noting that the Internet Resource Policy Evaluation Process had been followed, adopted the following policy proposals: * 2004-3: Global Addresses for Private Network Inter-Connectivity * 2004-5: Address Space for Multiple Discrete Networks * 2004-8: Allocation of IPv6 Address Space by the Internet Assigned Numbers Authority (IANA) Policy to Regional Internet Registries * 2005-3: Lame Delegations The following two policy proposals take effect today, September 7, 2005: * 2004-3: Global Addresses for Private Network Inter-Connectivity * 2004-5: Address Space for Multiple Discrete Networks Policy Proposal 2004-8 has been inserted into chapter 10 of the ARIN Number Resource Policy Manual (NRPM) as a proposed global policy. Editorial updates have been made in the NRPM per the recommendation of the Advisory Council and the subsequent adoption by the Board of Trustees at their meeting on August 8, 2005. Version 2005.1 of the NRPM is effective today, September 7, 2005. This version supersedes all previous versions. See Appendix A of the NRPM for information regarding changes to the manual. The NRPM can be found at: http://www.arin.net/policy/nrpm.html Appendix A can be found at: http://www.arin.net/policy/nrpm_changelog.html Board of Trustees minutes can be found at: http://www.arin.net/meetings/minutes/bot/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) From rich at nic.umass.edu Thu Sep 8 11:28:06 2005 From: rich at nic.umass.edu (Rich Emmings) Date: Thu, 8 Sep 2005 11:28:06 -0400 (EDT) Subject: [ppml] Proposed Policy: Proposal to amend ARIN IPv6 assignment and utilisation requirement In-Reply-To: <3F05EE24A82C0B42811178EFB8820C3F4654E1@AX-S-EX-1.stanleyassociates.com> References: <3F05EE24A82C0B42811178EFB8820C3F4654E1@AX-S-EX-1.stanleyassociates.com> Message-ID: I've been trying to get some time to give this the time it needs. >> Does this proposal help with a short term problem, or promote >> the adoption of IPv6? > > Since the potential problem is long term, we shouldn't do > anything about it? /56 or /48 today doesn't effect things in the long term, as we can adapt when needed to those, (or to a /60 or /52) once we have a track record and more real world experience. > >> Large scale introduction of /56 addresses may also increase >> the global routing table size. > > How? It might increase your local routing table size, but > ISPs (LIRs) will still aggregate at their borders, unless > leaking is required, and even then, a /56 doesn't take up > more router slots than a /48. > I'm guessing announcement of the longest prefixes will continue to happen in IPv6 for several reasons. I'll concede that it doesn't matter what the least prefix size is, /56 or /48, with regard to this, but my guts are telling me the smaller the prefixes out there, the more routes that will be there. > >> End site assignment of a /48 is a recommendation and nothing >> prohibits the assignment of a /56 downstream where appropriate. > > http://www.arin.net/policy/nrpm.html#six54 : > -- > 6.5.4. Assignment > > LIRs must make IPv6 assignments in accordance with the following > provisions. > > 6.5.4.1. Assignment address space size > > Assignments are to be made in accordance with the existing guidelines > (RFC3177,RIRs-on-48), which are summarized here as: > > - /48 in the general case, except for very large subscribers > 'general case' makes it a little soft for me, they could have used 'must' as above. but I'm not unwilling to concede it's a mandate. > So you advocate setting policy based on the .001% case? No > network left behind? No, more "let's get on with it" and deal with changes that are needed to implement, not keep polishing the cannonball. >> Changes slow implementation. That some of these changes are >> necessary doesn't alter the impact. >> At this time, this is an unnecessary change, so let's skip it >> and move on to implementation issues. > > I'm in favor of building right the first time, and in assigning > appropriate levels of resources. > There are 5 /3 blocks left reserved, all the size as 2000::/3. Less than half of 2000::/3 is allocated to RIR's. Once that space is allocated we'll have more real world information with which to backup decisions. There's a lot of space out there. I don't think many people fathom the concepts of 2^128. Even a mere billion dollars would take you over 10 years to spend at $10,000 per hour. No system will be perfect, we have room to adjust it later, and there's enough space out there that we're not at risk of running out over the short term. Perhaps table things for a year, or, until we need to think about issuing 4000::/3, and see what real world experiences suggest then? From david.conrad at nominum.com Thu Sep 8 11:53:56 2005 From: david.conrad at nominum.com (David Conrad) Date: Thu, 8 Sep 2005 08:53:56 -0700 Subject: [ppml] Proposed Policy: Proposal to amend ARIN IPv6 assignment and utilisation requirement In-Reply-To: References: <3F05EE24A82C0B42811178EFB8820C3F4654E1@AX-S-EX-1.stanleyassociates.com> Message-ID: <47128B79-3095-43F2-8A02-EFA54E2A7AF9@nominum.com> Hi, On Sep 8, 2005, at 8:28 AM, Rich Emmings wrote: > /56 or /48 today doesn't effect things in the long term, as we can > adapt > when needed to those, (or to a /60 or /52) once we have a track record > and more real world experience. In theory, true. In reality, I suspect developers will take shortcuts where they can. If there is a commandment that "thou shalt always have /48 or shorter", I suspect retrofitting longer prefixes will break lots of embedded stuff. > There's a lot of space out there. I don't think many people fathom > the > concepts of 2^128. And I don't think people understand that IPv6 is not really 2^128. Currently, it is between 2^48 and 2^64. Yes, both are still very, very large numbers however the RIRs are, even at this very early stage of deployment and before the promises of ubiquitous Internet connected devices is anywhere near reality, allocating /19s and /20s according to current policies. Obviously, there are the same number of /19s and /20s in IPv6 as there are in IPv4. > No system will be perfect, we have room to adjust it later, and > there's > enough space out there that we're not at risk of running out over > the short > term. > > Perhaps table things for a year, or, until we need to think about > issuing > 4000::/3, and see what real world experiences suggest then? As a person who has personally and repeatedly experienced first hand the repercussions of "historical inequities" in IPv4 addressing, I'm not sure it makes sense to repeat that particular IPv4 mistake. Rgds, -drc From rich at nic.umass.edu Thu Sep 8 13:29:52 2005 From: rich at nic.umass.edu (Rich Emmings) Date: Thu, 8 Sep 2005 13:29:52 -0400 (EDT) Subject: [ppml] Proposed Policy: Proposal to amend ARIN IPv6 assignment and utilisation requirement In-Reply-To: <47128B79-3095-43F2-8A02-EFA54E2A7AF9@nominum.com> References: <3F05EE24A82C0B42811178EFB8820C3F4654E1@AX-S-EX-1.stanleyassociates.com> <47128B79-3095-43F2-8A02-EFA54E2A7AF9@nominum.com> Message-ID: On Thu, 8 Sep 2005, David Conrad wrote: > > In theory, true. In reality, I suspect developers will take shortcuts where > they can. If there is a commandment that "thou shalt always have /48 or > shorter", I suspect retrofitting longer prefixes will break lots of embedded > stuff. One of the things that I feel will be true. CIDR or not in IPv4, there's a lot of classful legacy code out there that is still alive and living in your network, even in classless protocols. I can see 32 and/or 48 bit memory locations showing up in hardware based FIB's with some sort of punt when it's not an expected boundary. > >> There's a lot of space out there. I don't think many people fathom the >> concepts of 2^128. > > And I don't think people understand that IPv6 is not really 2^128. > Currently, it is between 2^48 and 2^64. Yes, both are still very, very large > numbers however the RIRs are, even at this very early stage of deployment and > before the promises of ubiquitous Internet connected devices is anywhere near > reality, allocating /19s and /20s according to current policies. Obviously, > there are the same number of /19s and /20s in IPv6 as there are in IPv4. > Agreed on both, and one of the things I try and remember is to subtract that /64 from the /prefix to get real numbers. Nevertheless, 2^64 is not only twice 2^32, and even with the reserved space is removed, there's still a very large amount of space out there. Nevertheless, pending rewrite of autoconfiguration, a /64 is what's gone. Even with that, 2^64 is a very large number -- if it was milliseconds, I'm not sure the universe has been around that long. To some extent, the proposal is a proponent of more free space available for the future, vs more free space available now. Someone with a /56 may possibly grow to a larger block or set of /56's. I would intuit that a /48 likely means single assignments for most everyone. Maybe the 0.001% mentioned elsewhere is the difference between /56's and /48's. > >> No system will be perfect, we have room to adjust it later, and there's >> enough space out there that we're not at risk of running out over the short >> term. >> >> Perhaps table things for a year, or, until we need to think about issuing >> 4000::/3, and see what real world experiences suggest then? > > As a person who has personally and repeatedly experienced first hand the > repercussions of "historical inequities" in IPv4 addressing, I'm not sure it > makes sense to repeat that particular IPv4 mistake. I've seen that too, however, we're less than 50% on 2000::/3 and haven't broached into the other 6 /3's that would be available at some point. We have more room to make adjustments than with IPv4 space. If the finite space was just 2000::/3 and were approaching 50%, allocation size would be a more important factor than getting things more set in concrete. I run into issues with rollout related to "Well, they're still changing things, let's wait" I'm willing to accept a less than perfect initial system that has room to be moved into a more perfect state at a later date. From Lee.Howard at stanleyassociates.com Thu Sep 8 16:21:25 2005 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Thu, 8 Sep 2005 16:21:25 -0400 Subject: [ppml] Proposed Policy: Proposal to amend ARIN IPv6 assignment and utilisation requirement Message-ID: <3F05EE24A82C0B42811178EFB8820C3F589CD8@AX-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: Rich Emmings [mailto:rich at nic.umass.edu] > Sent: Thursday, September 08, 2005 1:30 PM > To: David Conrad > Cc: Howard, W. Lee; ppml at arin.net > Subject: Re: [ppml] Proposed Policy: Proposal to amend ARIN > IPv6 assignment and utilisation requirement > > On Thu, 8 Sep 2005, David Conrad wrote: > > >> There's a lot of space out there. I don't think many > people fathom the > >> concepts of 2^128. > > > > And I don't think people understand that IPv6 is not really 2^128. > > Currently, it is between 2^48 and 2^64. Yes, both are > still very, very large > > numbers however the RIRs are, even at this very early stage > of deployment and > > before the promises of ubiquitous Internet connected > devices is anywhere near > > reality, allocating /19s and /20s according to current > policies. Obviously, > > there are the same number of /19s and /20s in IPv6 as there > are in IPv4. > > > > Agreed on both, and one of the things I try and remember is > to subtract > that /64 from the /prefix to get real numbers. Nevertheless, > 2^64 is not > only twice 2^32, and even with the reserved space is removed, > there's still > a very large amount of space out there. Nevertheless, > pending rewrite of > autoconfiguration, a /64 is what's gone. Twice 2^32 is 2^33. 2^64 is 2^32^2 > Even with that, 2^64 is a very large number -- if it was > milliseconds, I'm > not sure the universe has been around that long. 2^64 = 18446744073709551616 milliseconds 584,942,417 years Depending on your religion, worms, mulluscs, and arthropods slithered the earth, or the universe wasn't born yet. > To some extent, the proposal is a proponent of more free > space available for > the future, vs more free space available now. Someone with a /56 may > possibly grow to a larger block or set of /56's. I would > intuit that a /48 > likely means single assignments for most everyone. Maybe the 0.001% > mentioned elsewhere is the difference between /56's and /48's. I can accept your characterization of the debate. I think it's harder to change policy than you do. I don't think anyone who needs a /64 will outgrow a /56 within the currently projected life of IPv6. > > As a person who has personally and repeatedly experienced > first hand the > > repercussions of "historical inequities" in IPv4 > addressing, I'm not sure it > > makes sense to repeat that particular IPv4 mistake. > > I've seen that too, however, we're less than 50% on 2000::/3 > and haven't > broached into the other 6 /3's that would be available at > some point. We > have more room to make adjustments than with IPv4 space. If > the finite > space was just 2000::/3 and were approaching 50%, allocation > size would be a > more important factor than getting things more set in concrete. It's easier to loosen the belt than tighten it. If we try to restrict things later, late adopters will cry "Foul!" and it'll be worse than now, since we have a chance to learn from history, and since this time around people think it's important. Don't get me wrong--I'm not saying we should give people less than they need. I just don't think we need to give them 65,000 times what they need (and nevermind those last 64 bits). > I run into issues with rollout related to "Well, they're > still changing > things, let's wait" I'm willing to accept a less than > perfect initial > system that has room to be moved into a more perfect state at > a later date. Could we at least avoid making the mistakes we already know about? Lee From andrew.dul at quark.net Mon Sep 12 22:10:27 2005 From: andrew.dul at quark.net (Andrew Dul) Date: Mon, 12 Sep 2005 19:10:27 -0700 Subject: [ppml] ARIN Policy Proposal 2005-4: AfriNIC Recognition Policy Message-ID: <4.0.2.20050912185004.01b90960@mail.quark.net> This policy will be discussed at the upcoming ARIN meeting, if you have any comments regarding this policy proposal we encouage you to post to ppml at arin.net to discuss this issue. Thanks, Andrew ARIN AC > > >### * ### > > >Policy Proposal Name: AfriNIC Recognition Policy > >Author: Andrew Dul > >Policy term: permanent > >Policy statement: Remove section 4.8 entitled "Policy for the African >Portion of the ARIN Region" of the NRPM. > >Rationale: The ARIN BoT recently suspended section 4.8 of the NRPM upon >recognition of AfriNIC as an RIR by ICANN. Section 4.8 of the NRPM >applied only to areas of the ARIN region that are now covered by AfriNIC. > >Timetable for implementation: Within 30 days of ratification by the BoT. > From andrew.dul at quark.net Mon Sep 12 22:10:52 2005 From: andrew.dul at quark.net (Andrew Dul) Date: Mon, 12 Sep 2005 19:10:52 -0700 Subject: [ppml] Policy Proposal 2005-5: IPv6 HD ratio Message-ID: <4.0.2.20050912185518.01ca4e18@mail.quark.net> Hello, This policy proposal will be discussed at the upcoming ARIN meeting. We encourage you to voice your opinions regarding this policy on the mailing list prior to the meeting so the issues can be discussed. A similar policy was recently discussed at the APNIC meeting in Hanoi, and it appeared that there was rough consensus at the meeting to move the HD ratio portion of the APNIC policy back to the APNIC mailing-list for the additional comment period per the APNIC policy process. Consensus did not appear to be reached on the end-site subnet size of the APNIC policy (ARIN policy proposal 2005-8). http://www.apnic.net/docs/policy/proposals/prop-031-v001.html Thanks, Andrew ARIN AC > >### * ### > > >Policy Proposal Name: IPv6 HD ratio > >Author: Andrew Dul > >Policy term: permanent > >Policy statement: Change HD ratio used for IPv6 allocations to 0.94 > >This would modify sections 6.5.2.2 & 6.7 (including the HD-ratio to >percentage table) of the NRPM. > >Rationale: Recent research has shown that based upon certain growth >models the current IPv6 allocation policy using the HD ratio of 0.8 will >allocate between a >/1 and /4 of Ipv6 address space over the period of about 60 years. > >http://www.ietf.org/internet-drafts/draft-huston-ipv6-hd-metric-00.txt > >By changing the HD ratio to 0.94, this would require LIRs to have a >higher utilization of the /48s that are assigned to end sites before >being able to obtain additional allocations. This policy would change >the threshold for an LIR holding a /32 from approximately 11% to 51%. >An LIR with a /20 would have a utilized percentage of approximately 31% >vs. the current 2%. > >This policy may also prevent the hoarding of IPv6 addresses by current >organizations with large customer bases, but no substantial current IPv6 >network. > >Timetable for implementation: Within 30 days of ratification by the BoT. > From william at elan.net Mon Sep 12 22:18:37 2005 From: william at elan.net (william(at)elan.net) Date: Mon, 12 Sep 2005 19:18:37 -0700 (PDT) Subject: [ppml] Policy Proposal 2005-5: IPv6 HD ratio In-Reply-To: <4.0.2.20050912185518.01ca4e18@mail.quark.net> References: <4.0.2.20050912185518.01ca4e18@mail.quark.net> Message-ID: On Mon, 12 Sep 2005, Andrew Dul wrote: > A similar policy was recently discussed at the APNIC meeting in Hanoi, and > it appeared that there was rough consensus at the meeting to move the HD > ratio portion of the APNIC policy back to the APNIC mailing-list for the > additional comment period per the APNIC policy process. Does it mean there was consensus at APNIC to change the HD ration or agreement that issue needs to be discussed more but that there is no consensus how or if it should be changed? -- William Leibzon Elan Networks william at elan.net From andrew.dul at quark.net Mon Sep 12 22:20:53 2005 From: andrew.dul at quark.net (Andrew Dul) Date: Mon, 12 Sep 2005 19:20:53 -0700 Subject: [ppml] Policy Proposal 2005-5: IPv6 HD ratio In-Reply-To: References: <4.0.2.20050912185518.01ca4e18@mail.quark.net> <4.0.2.20050912185518.01ca4e18@mail.quark.net> Message-ID: <20050913022107.772AA14456D@smtp2.arin.net> At 07:18 PM 9/12/2005 -0700, william(at)elan.net wrote: > >On Mon, 12 Sep 2005, Andrew Dul wrote: > >> A similar policy was recently discussed at the APNIC meeting in Hanoi, and >> it appeared that there was rough consensus at the meeting to move the HD >> ratio portion of the APNIC policy back to the APNIC mailing-list for the >> additional comment period per the APNIC policy process. > >Does it mean there was consensus at APNIC to change the HD ration or >agreement that issue needs to be discussed more but that there is no >consensus how or if it should be changed? Consenus of the room appeared to be to change the HD ratio from 0.8 to 0.94. Andrew From anne at apnic.net Tue Sep 13 01:06:45 2005 From: anne at apnic.net (Anne Lord) Date: Tue, 13 Sep 2005 15:06:45 +1000 Subject: [ppml] Policy Proposal 2005-5: IPv6 HD ratio In-Reply-To: <20050913022107.772AA14456D@smtp2.arin.net> References: <4.0.2.20050912185518.01ca4e18@mail.quark.net> <4.0.2.20050912185518.01ca4e18@mail.quark.net> <20050913022107.772AA14456D@smtp2.arin.net> Message-ID: <43265E65.8000009@apnic.net> hi, Andrew Dul wrote: > At 07:18 PM 9/12/2005 -0700, william(at)elan.net wrote: > >>On Mon, 12 Sep 2005, Andrew Dul wrote: >> >> >>>A similar policy was recently discussed at the APNIC meeting in Hanoi, and >>>it appeared that there was rough consensus at the meeting to move the HD >>>ratio portion of the APNIC policy back to the APNIC mailing-list for the >>>additional comment period per the APNIC policy process. >> >>Does it mean there was consensus at APNIC to change the HD ration or >>agreement that issue needs to be discussed more but that there is no >>consensus how or if it should be changed? > > > Consenus of the room appeared to be to change the HD ratio from 0.8 to 0.94. This is correct. This was the consensus. However there are a few more steps in the process before 'consensus' is finally declared. Just to clarify, the APNIC policy process requires all policy proposals that reached consensus at the SIGs to also reach consensus at the Member meeting on the last day of the meeting programme. The policy is then circulated on the mailing list for a period of 8 weeks to allow further comment and input from the community. If there are no substantial objections during this period, it is then put to the EC to endorse the proposal. (Details of the process are documented here: http://www.apnic.net/docs/policy/dev/process.html) regards, Anne -- From randy at psg.com Tue Sep 13 04:42:30 2005 From: randy at psg.com (Randy Bush) Date: Tue, 13 Sep 2005 15:42:30 +0700 Subject: [ppml] Policy Proposal 2005-5: IPv6 HD ratio References: <4.0.2.20050912185518.01ca4e18@mail.quark.net> Message-ID: <17190.37110.682749.533517@roam.psg.com> > Consensus did not appear to be reached on the end-site subnet > size of the APNIC policy (ARIN policy proposal 2005-8). the basis for this rejection was seeing that /56, /48/, ... are classful addresses all over again. and enough folk who had lived through the classful disaster last time happened to be in the room. it was suggested that, iff some idealized subnet size is needed to calculate some ratios, that /42 be used. randy From Ed.Lewis at neustar.biz Fri Sep 16 10:25:54 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Fri, 16 Sep 2005 10:25:54 -0400 Subject: [ppml] Policy Proposal 2005-5: IPv6 HD ratio In-Reply-To: <17190.37110.682749.533517@roam.psg.com> References: <4.0.2.20050912185518.01ca4e18@mail.quark.net> <17190.37110.682749.533517@roam.psg.com> Message-ID: At 15:42 +0700 9/13/05, Randy Bush wrote: >> Consensus did not appear to be reached on the end-site subnet >> size of the APNIC policy (ARIN policy proposal 2005-8). > >the basis for this rejection was seeing that /56, /48/, ... are >classful addresses all over again. and enough folk who had lived >through the classful disaster last time happened to be in the room. Some other comments made by attendees: NIRs and LIRs in the APNIC region have already built their address management software around the /48 size, to them seeing a different size in a policy proposal would be a real pain. Even if the space they have already doled out was "grand-fathered" to be /48's and not /56's, they would still incur a cost of some retooling. I.e., in the APNIC region, IPv6 is already past "early adopter" status. Having heard discussions of this proposal at ARIN, RIPE and APNIC, I came up with a suggestion to eliminate any operational recommendation from the proposal as this always seems to engender a rat hole argument over how to use IPv6. I.e., drop the "/48 vs. /56" discussion from the policy. Instead, the policy ought to me more clearly focused on "measurement of address use" for the sake of deciding when more space is to be granted. This is partly a wording trick to clarify the intent of the policy and to keep discussion from rat holing. But this is more than just a trick - it's also trying to keep RIR policies in the realm where "they belong," i.e., address management and not operational directives. (The HD ratio change is well within the bailiwick of address allocation management.) From http://www.apnic.net/meetings/20/docs/transcripts/policy-sig.txt: "GEOFF HUSTON: Usage rather than recommended deployment is what you're saying, thank you." -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From memsvcs at arin.net Mon Sep 19 15:46:09 2005 From: memsvcs at arin.net (Member Services) Date: Mon, 19 Sep 2005 15:46:09 -0400 Subject: [ppml] The Open Policy Hour Message-ID: <432F1581.5080101@arin.net> Do you have an idea about how ARIN should manage Internet Number Resources? Do you think that a current policy should be enhanced or changed, or even retired? Are you hesitant about making a formal proposal on the Public Policy Mail List (PPML)? Are you new to the Policy Development Process? If the answer to any of these questions is yes, then you should attend THE OPEN POLICY HOUR! What is THE OPEN POLICY HOUR? Quite simply, it is your opportunity to discuss your ideas in an open, informal forum and receive feedback. It is not a review session of the policies that will be discussed during the ARIN XVI Public Policy meeting, nor is it a requirement for a policy to be considered in the ARIN Internet Resource Policy Evaluation Process. There are no minutes of this meeting. How can you participate? Bring your ideas and questions. If you have a policy proposal for which you would like to receive feedback prior to submitting it to the community on the PPML, here is your opportunity. If you have a short (3-minute) presentation prepared you can do it at this session, in fact you will be given the first opportunity to present it. To sign up to give a presentation please send an e-mail to policy at arin.net by October 14, 2005, with your name, organization, and a general description of your policy subject. Come join your colleagues in this informal setting. THE OPEN POLICY HOUR for ARIN XVI will be held on Tuesday, October 25, from 6:00 - 6:45 PM. Registration for ARIN XVI is simple. Registration and hotel details are at: http://www.arin.net/ARIN-XVI/ Agenda details are at: http://www.arin.net/ARIN-XVI/agenda.html Contact Member Services at memsvcs at arin.net if you have any questions. Regards, Member Services Department American Registry for Internet Numbers =========================================================================== Register now for ARIN XVI being held in Los Angeles, CA, October 26-28, 2005! http://www.arin.net/ARIN-XVI/ =========================================================================== =========================================================================== E-mail memsvcs at arin.net FTP ftp.arin.net WHOIS whois.arin.net Website http://www.arin.net =========================================================================== From memsvcs at arin.net Fri Sep 23 13:36:21 2005 From: memsvcs at arin.net (Member Services) Date: Fri, 23 Sep 2005 13:36:21 -0400 Subject: [ppml] Policy Proposal 2005-1: Provider Independent IPv6 Assignments for End-sites - Revised Text Message-ID: <43343D15.9000903@arin.net> Policy Proposal 2005-1: Provider Independent IPv6 Assignments for End-sites has been revised by the authors. This proposal is open for discussion on the mailing list and will be on the agenda at the upcoming Public Policy Meeting. The current policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2005_1.html Regards, Member Services Department American Registry for Internet Numbers ### * ### Policy Proposal 2005-1: Provider Independent IPv6 Assignments for End-sites Author: Owen Delong, Kevin Loch Policy statement: Add new subsection to the NRPM: 6.5.8. Direct assignments to end sites 6.5.8.1. To qualify for a direct end site assignment, an organization must: 1. not be an LIR; 2. be an end site; 3. be currently multihomed using IPv6 to two or more separate LIR's using at least one /48 assigned to them by each LIR. 4. be able to assign IPv6 addresses to at least 100,000 unique devices within 1 year and advertise that connectivity through it's single aggregated address assignment. 6.5.8.2. Direct assignment size to end sites Organizations that meet the direct end site assignment criteria are eligible to receive a direct assignment of /44 6.5.8.3. Subsequent direct assignments to end sites Only one direct assignment may be made to an end site organization under Section 6.5.8 Rationale: The original proposal 2005-1 would have provided for a Provider Independent IPv6 allocation to anyone who could qualify for an Autonomous System number. While this proposal failed to reach consensus at the ARIN XV meeting in Orlando in April 2005, the Advisory Council agreed there was sufficient interest in the proposal to see if it could be recrafted into a proposal capable of reaching consensus. The main objections to the original 2005-1 were a concern over a run on AS numbers, which are currently the most constrained Internet Resource until 4-byte ASN's are a reality, and major concerns over the possibility of a large increase in the size of the IPv6 default-free routing table. There were assertions that it was too early for making multi-homing alone a rationale for a direct assignment of IPv6 address space, unless it was only for a limited time, until the viability of the shim6 effort in IETF could be determined. While the current number of sites who multi-home could easily be accomodated at this time, the effect of an IPv6 policy has to be looked at over the multiple 10s of years that IPv6 will need to be functional. Very few people believed that limited time assignments were viable (i.e. could actually be reclaimed) and asserted that it would create a similar situation to IPv4, where early adopters have an unfair advantage. In support of the proposal, a number of commercial companies, who were attending the co-located NAv6TF meeting, expressed their unwillingness to invest resources in deploying IPv6 with Provider Assigned address space, as they were unwilling to be "locked in" to a provider or else have to renumber their entire enterprise. When the sense of the room was taken, the attendees were about evenly split and so there was clearly not a consensus. Discussions with those who opposed the advancement of 2005-1 indicated they were very concerned about almost unlimited access to Provider Independent IPv6 address assignments. They indicated that it was too early in the protocol's lifetime to allow unrestricted routing table growth and expressed the hope that shim6 might still be successful. There is a real belief that IPv4-like multi-homing will doom the IPv6 routing table to grow beyond a workable size and some other solution must be found! Many of them expressed an understanding of the large organization renumbering problem and indicated that they would support a policy that provided for PI address assignments to a small number of large organizations for whom the cost of renumbering would be a significant expense. So this new version of proposal 2005-1 has been reworked to apply to a much more limited number of organizations and should not lead to unrestricted growth of the IPv6 routing table. Timetable for implementation: immediate From Ed.Lewis at neustar.biz Fri Sep 23 14:12:25 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Fri, 23 Sep 2005 14:12:25 -0400 Subject: [ppml] Policy Proposal 2005-1: Provider Independent IPv6 Assignments for End-sites - Revised Text In-Reply-To: <43343D15.9000903@arin.net> References: <43343D15.9000903@arin.net> Message-ID: At 13:36 -0400 9/23/05, Member Services wrote: >http://www.arin.net/policy/proposals/2005_1.html >Policy Proposal 2005-1: Provider Independent IPv6 Assignments for End-sites > 4. be able to assign IPv6 addresses to at least 100,000 >unique devices within 1 year and advertise that connectivity through >it's single aggregated address assignment. I'm curious about the rationale for "100,000." Not that I think it is unreasonable, but was there any reason to pick that amount? Perhaps something to do with the pain of renumbering? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From memsvcs at arin.net Mon Sep 26 10:56:56 2005 From: memsvcs at arin.net (Member Services) Date: Mon, 26 Sep 2005 10:56:56 -0400 Subject: [ppml] ARIN XVI - Policy Proposals Message-ID: <43380C38.7070200@arin.net> ARIN will hold its next Public Policy and Members Meeting in Los Angeles on October 26-28, 2005. Meeting and registration details can be found at: http://www.arin.net/ARIN-XVI/index.html Policy discussions at this meeting will be centered on policy proposals recently introduced to the Public Policy Mailing List (PPML), and those carried over from the previous Public Policy Meeting. Policy Proposals recently introduced on PPML: 2005-4: AfriNIC Recognition Policy 2005-5: IPv6 HD ratio 2005-6: IPv4 Micro-allocations for Anycast Services 2005-7: Rationalize Multi-Homing Definition and Requirement 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement Policy Proposals carried over from the previous Public Policy Meeting: 2005-1: Provider Independent IPv6 Assignments for End-sites 2005-2: Directory Services Overhaul Policy proposals are open for discussion on PPML. Each of the policy proposals has been previously posted to this mailing list as an independent thread to facilitate discussion. A summary of the active policy proposals under discussion can be found at: http://www.arin.net/policy/proposal_archive.html The entire Internet community is invited and encouraged to participate in these policy discussions. Your active participation in these discussions is vital to the process and will help to form policies that are beneficial to all. Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services Department American Registry for Internet Numbers ============================================================================= Register now for ARIN XVI being held in Los Angeles, CA, October 26-28, 2005! http://www.arin.net/ARIN-XVI/ ============================================================================= ============================================================================= E-mail memsvcs at arin.net FTP ftp.arin.net WHOIS whois.arin.net Website http://www.arin.net ============================================================================= From tme at multicasttech.com Mon Sep 26 11:46:39 2005 From: tme at multicasttech.com (Marshall Eubanks) Date: Mon, 26 Sep 2005 11:46:39 -0400 Subject: [ppml] Policy Proposal 2005-1: Provider Independent IPv6 Assignments for End-sites - Revised Text In-Reply-To: <43343D15.9000903@arin.net> Message-ID: Hello; This proposal seems like such a radical change in the original 2005-1 (unless I am reading it incorrectly) that frankly I think it would have been more appropriate to have given it a new designation. (BTW, was there discussion of the 100,000 end nodes requirements on the list ? I don't recall any.) Note that, for most end users, a device connected to the Internet is likely to cost order $ 1000 each, and there is likely to be no more than 2 or 3 Internet connected devices per employee. So, we are talking about making /48 address blocks directly available to large corporations, with a minimum of $ 100 million in equipment expenditures. That is not the spirit that I understood the original 2005-1, which was (at least in my understanding) aimed more at companies that needed to multihome, without such a strict size filters. I cannot support the current 2005-1 as I read it. I welcome attempts to convince me of the errors of my ways. Regards Marshall Eubanks On Fri, 23 Sep 2005 13:36:21 -0400 Member Services wrote: > Policy Proposal 2005-1: Provider Independent IPv6 Assignments for > End-sites has been revised by the authors. This proposal is open for > discussion on the mailing list and will be on the agenda at the upcoming > Public Policy Meeting. > > The current policy proposal text is provided below and is also available at: > http://www.arin.net/policy/proposals/2005_1.html > > Regards, > > Member Services Department > American Registry for Internet Numbers > > > ### * ### > > > Policy Proposal 2005-1: Provider Independent IPv6 Assignments for End-sites > > Author: Owen Delong, Kevin Loch > > Policy statement: > > Add new subsection to the NRPM: > > 6.5.8. Direct assignments to end sites > > 6.5.8.1. To qualify for a direct end site assignment, an > organization must: > > 1. not be an LIR; > 2. be an end site; > 3. be currently multihomed using IPv6 to two or more > separate LIR's using at least one /48 assigned to them by each LIR. > 4. be able to assign IPv6 addresses to at least 100,000 > unique devices within 1 year and advertise that connectivity through > it's single aggregated address assignment. > > 6.5.8.2. Direct assignment size to end sites > > Organizations that meet the direct end site assignment criteria > are eligible to receive a direct assignment of /44 > 6.5.8.3. Subsequent direct assignments to end sites > > Only one direct assignment may be made to an end site > organization under Section 6.5.8 > > Rationale: > > The original proposal 2005-1 would have provided for a Provider > Independent IPv6 allocation to anyone who could qualify for an > Autonomous System number. While this proposal failed to reach consensus > at the ARIN XV meeting in Orlando in April 2005, the Advisory Council > agreed there was sufficient interest in the proposal to see if it could > be recrafted into a proposal capable of reaching consensus. > > The main objections to the original 2005-1 were a concern over a run on > AS numbers, which are currently the most constrained Internet Resource > until 4-byte ASN's are a reality, and major concerns over the > possibility of a large increase in the size of the IPv6 default-free > routing table. There were assertions that it was too early for making > multi-homing alone a rationale for a direct assignment of IPv6 address > space, unless it was only for a limited time, until the viability of the > shim6 effort in IETF could be determined. While the current number of > sites who multi-home could easily be accomodated at this time, the > effect of an IPv6 policy has to be looked at over the multiple 10s of > years that IPv6 will need to be functional. Very few people believed > that limited time assignments were viable (i.e. could actually be > reclaimed) and asserted that it would create a similar situation to > IPv4, where early adopters have an unfair advantage. In support of the > proposal, a number of commercial companies, who were attending the > co-located NAv6TF meeting, expressed their unwillingness to invest > resources in deploying IPv6 with Provider Assigned address space, as > they were unwilling to be "locked in" to a provider or else have to > renumber their entire enterprise. When the sense of the room was taken, > the attendees were about evenly split and so there was clearly not a > consensus. > > Discussions with those who opposed the advancement of 2005-1 indicated > they were very concerned about almost unlimited access to Provider > Independent IPv6 address assignments. They indicated that it was too > early in the protocol's lifetime to allow unrestricted routing table > growth and expressed the hope that shim6 might still be successful. > > There is a real belief that IPv4-like multi-homing will doom the IPv6 > routing table to grow beyond a workable size and some other solution > must be found! Many of them expressed an understanding of the large > organization renumbering problem and indicated that they would support a > policy that provided for PI address assignments to a small number of > large organizations for whom the cost of renumbering would be a > significant expense. > > So this new version of proposal 2005-1 has been reworked to apply to a > much more limited number of organizations and should not lead to > unrestricted growth of the IPv6 routing table. > > Timetable for implementation: immediate > > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From Ed.Lewis at neustar.biz Mon Sep 26 12:07:29 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 26 Sep 2005 12:07:29 -0400 Subject: [ppml] 2005-2, was Re: ARIN XVI - Policy Proposals In-Reply-To: <43380C38.7070200@arin.net> References: <43380C38.7070200@arin.net> Message-ID: At 10:56 -0400 9/26/05, Member Services wrote: >ARIN will hold its next Public Policy and Members Meeting in Los Angeles >on October 26-28, 2005. Meeting and registration details can be found at: >http://www.arin.net/ARIN-XVI/index.html > ... > >Policy Proposals carried over from the previous Public Policy Meeting: ... >2005-2: Directory Services Overhaul There has been a lot of email on this, but not recently. (The last I found was dated mid-June.) To me it doesn't look like the on-line version of the policy reflects any of the post-Orlando discussion. Considering the volume of discussion until mid-June, the amount of territory this (ambitious) rewrite covers, and the limited time available in LA to talk about this, it seems that it would be good to have a "state of this policy proposal" documented somewhere. (I say limited because, no matter what the percentage of meeting time is dedicated to this topic, it won't be enough to get this proposal done. Every time a v6 proposal is put up - it strives to consume all available time too.) If I could dedicate the time to summarize this, I'd volunteer, but I can't. I'd also feel out of place as I'm not the author/editor/submitter of the proposal. (I'm not trying to point a finger at Leo and say he should do it, rather my summary would carry no real weight.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From bicknell at ufp.org Mon Sep 26 14:25:19 2005 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 26 Sep 2005 14:25:19 -0400 Subject: [ppml] 2005-2, was Re: ARIN XVI - Policy Proposals In-Reply-To: References: <43380C38.7070200@arin.net> Message-ID: <20050926182519.GA93658@ussenterprise.ufp.org> In a message written on Mon, Sep 26, 2005 at 12:07:29PM -0400, Edward Lewis wrote: > If I could dedicate the time to summarize this, I'd volunteer, but I > can't. I'd also feel out of place as I'm not the > author/editor/submitter of the proposal. (I'm not trying to point a > finger at Leo and say he should do it, rather my summary would carry > no real weight.) I'm already working on such a summary. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From owen at delong.com Tue Sep 27 06:38:19 2005 From: owen at delong.com (Owen DeLong) Date: Tue, 27 Sep 2005 03:38:19 -0700 Subject: [ppml] Policy Proposal 2005-1: Provider Independent IPv6 Assignments for End-sites - Revised Text In-Reply-To: References: Message-ID: You are completely correct. It is a compromise to try and get some form of PI policy on the books, then, be able in a year or two, to point to it and say "See... No land rush, now can we do something reasonable?". There is just too much religion about not giving PI space to "small" organizations to achieve consensus around the original 2005-1. Between the AC representatives that worked with us, Kevin (who authored another similar policy which was merged with 2005-1), and myself, we decided that this was the best way to go to achieve consensus and get a policy on the books. I hope that given that, you will be able to support the policy moving forward so that we can get some experience on the book to try and relax the requirements. In my experience, it is usually easier to reduce requirements gradually than to try and open a floodgate policy all at once. It was made very clear from the last meeting that there are too many opponents to the idea of giving PI space to any multihomed organization in the v6 world. In my opinion, this is short sighted, unfair, impractical, and, elitest on the part of the large organizations that are pushing this policy. However, there are some practical considerations as well (ASN exhaustion and Routing Table growth). In my opinion, we need to solve these issues through technology (32 bit ASNs and better ways to manage routing) instead of through restrictive and capricious address policy. However, the tools available today in ARIN are policy, not technology, so, we have to work with what we have. Thus the current compromise. Owen --On September 26, 2005 11:46:39 AM -0400 Marshall Eubanks wrote: > Hello; > > This proposal seems like such a radical change in the original 2005-1 > (unless I am reading it incorrectly) that frankly I think it would have > been more appropriate to have given it a new designation. > > (BTW, was there discussion of the 100,000 end nodes requirements on the > list ? I don't recall any.) > > Note that, for most end users, a device connected to the Internet is > likely to cost order $ 1000 each, and there is likely to be no more than > 2 or 3 Internet connected devices per employee. So, we are talking about > making /48 address blocks directly available to large corporations, with > a minimum of $ 100 million in equipment expenditures. That is not the > spirit that I understood the original 2005-1, which was (at least in my > understanding) aimed more at companies that needed to multihome, without > such a strict size filters. > > I cannot support the current 2005-1 as I read it. I welcome attempts to > convince me of the errors of my ways. > > Regards > Marshall Eubanks > > > On Fri, 23 Sep 2005 13:36:21 -0400 > Member Services wrote: >> Policy Proposal 2005-1: Provider Independent IPv6 Assignments for >> End-sites has been revised by the authors. This proposal is open for >> discussion on the mailing list and will be on the agenda at the upcoming >> Public Policy Meeting. >> >> The current policy proposal text is provided below and is also available >> at: http://www.arin.net/policy/proposals/2005_1.html >> >> Regards, >> >> Member Services Department >> American Registry for Internet Numbers >> >> >> ### * ### >> >> >> Policy Proposal 2005-1: Provider Independent IPv6 Assignments for >> End-sites >> >> Author: Owen Delong, Kevin Loch >> >> Policy statement: >> >> Add new subsection to the NRPM: >> >> 6.5.8. Direct assignments to end sites >> >> 6.5.8.1. To qualify for a direct end site assignment, an >> organization must: >> >> 1. not be an LIR; >> 2. be an end site; >> 3. be currently multihomed using IPv6 to two or more >> separate LIR's using at least one /48 assigned to them by each LIR. >> 4. be able to assign IPv6 addresses to at least 100,000 >> unique devices within 1 year and advertise that connectivity through >> it's single aggregated address assignment. >> >> 6.5.8.2. Direct assignment size to end sites >> >> Organizations that meet the direct end site assignment criteria >> are eligible to receive a direct assignment of /44 >> 6.5.8.3. Subsequent direct assignments to end sites >> >> Only one direct assignment may be made to an end site >> organization under Section 6.5.8 >> >> Rationale: >> >> The original proposal 2005-1 would have provided for a Provider >> Independent IPv6 allocation to anyone who could qualify for an >> Autonomous System number. While this proposal failed to reach consensus >> at the ARIN XV meeting in Orlando in April 2005, the Advisory Council >> agreed there was sufficient interest in the proposal to see if it could >> be recrafted into a proposal capable of reaching consensus. >> >> The main objections to the original 2005-1 were a concern over a run on >> AS numbers, which are currently the most constrained Internet Resource >> until 4-byte ASN's are a reality, and major concerns over the >> possibility of a large increase in the size of the IPv6 default-free >> routing table. There were assertions that it was too early for making >> multi-homing alone a rationale for a direct assignment of IPv6 address >> space, unless it was only for a limited time, until the viability of the >> shim6 effort in IETF could be determined. While the current number of >> sites who multi-home could easily be accomodated at this time, the >> effect of an IPv6 policy has to be looked at over the multiple 10s of >> years that IPv6 will need to be functional. Very few people believed >> that limited time assignments were viable (i.e. could actually be >> reclaimed) and asserted that it would create a similar situation to >> IPv4, where early adopters have an unfair advantage. In support of the >> proposal, a number of commercial companies, who were attending the >> co-located NAv6TF meeting, expressed their unwillingness to invest >> resources in deploying IPv6 with Provider Assigned address space, as >> they were unwilling to be "locked in" to a provider or else have to >> renumber their entire enterprise. When the sense of the room was taken, >> the attendees were about evenly split and so there was clearly not a >> consensus. >> >> Discussions with those who opposed the advancement of 2005-1 indicated >> they were very concerned about almost unlimited access to Provider >> Independent IPv6 address assignments. They indicated that it was too >> early in the protocol's lifetime to allow unrestricted routing table >> growth and expressed the hope that shim6 might still be successful. >> >> There is a real belief that IPv4-like multi-homing will doom the IPv6 >> routing table to grow beyond a workable size and some other solution >> must be found! Many of them expressed an understanding of the large >> organization renumbering problem and indicated that they would support a >> policy that provided for PI address assignments to a small number of >> large organizations for whom the cost of renumbering would be a >> significant expense. >> >> So this new version of proposal 2005-1 has been reworked to apply to a >> much more limited number of organizations and should not lead to >> unrestricted growth of the IPv6 routing table. >> >> Timetable for implementation: immediate >> >> >> >> _______________________________________________ >> PPML mailing list >> PPML at arin.net >> http://lists.arin.net/mailman/listinfo/ppml > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From jim at tgasolutions.com Tue Sep 27 07:02:43 2005 From: jim at tgasolutions.com (Jim McBurnett) Date: Tue, 27 Sep 2005 07:02:43 -0400 Subject: [ppml] Policy Proposal 2005-7: Rationalize Multi-Homing Definitionand Requirement Message-ID: <5432D045DAFD8040BCE549749263BD0032EAB3@testsystem2.tga.local> Robert, Can this policy we modified to also address end user sites? I just saw another question on NANOG and it made me take a closer look... Thanks, Jim -----Original Message----- From: Robert E.Seastrom [mailto:rs at seastrom.com] Sent: Monday, September 05, 2005 9:32 PM To: Jim McBurnett Cc: Member Services; ppml at arin.net Subject: Re: [ppml] Policy Proposal 2005-7: Rationalize Multi-Homing Definitionand Requirement "Jim McBurnett" writes: > Interesting... > I called the helpdesk a little while back and asked for a multi-homing > block for a customer that was about to dump their primary carrier and > become multi-homed and was denied. > > I was told the denial was because the customer was not currently > multi-homed and at face value could not justify a /22. > > So under this policy, I believe the customer would have been approved. Well, you *do* still have to justify the /22. :) > With HIPPA, Sarbox, and the financial equivilent, our customers are > moving to multi-homing. > Most want a /23 or /24, and from my experience I have seen 1 to 2 week > delays in getting IP's from some ISPs. > This may really help the SMB market that wants to multi-home. Only if they can justify the minimum PI allocation (which is an orthogonal problem to the one that 2005-7 attempts to address). ---Rob From kloch at hotnic.net Wed Sep 28 05:16:59 2005 From: kloch at hotnic.net (Kevin Loch) Date: Wed, 28 Sep 2005 05:16:59 -0400 Subject: [ppml] Policy Proposal 2005-1: Provider Independent IPv6 Assignments for End-sites - Revised Text In-Reply-To: References: <43343D15.9000903@arin.net> Message-ID: <433A5F8B.4040705@hotnic.net> Edward Lewis wrote: >> 4. be able to assign IPv6 addresses to at least 100,000 >>unique devices within 1 year and advertise that connectivity through >>it's single aggregated address assignment. > > > I'm curious about the rationale for "100,000." Not that I think it > is unreasonable, but was there any reason to pick that amount? > Perhaps something to do with the pain of renumbering? No precision is implied in that number. The rationale is that lower magnitudes might allow too many end sites to qualify for PI space. There is significant concern that policy mistakes made early on will have long lasting if not permanent effects on routing table size. 100,000 devices appeared to be a number that could overcome the opposition from the last meeting (as opposed to 10,000 for example). Personally I agree with Owen that 100,000 devices is absurdly high. I think a good target would be normalizing with IPv4 multihoming (~400 devices) or non multihoming (~1600 devices) requirements. But in the interest of getting the framework in place and at least some end site assignemnts made I agreed to put the device requirement in there. I made sure it was easy to reduce or eliminate the device requirement in the future without having to rewrite the rest of the section. - Kevin From kloch at hotnic.net Wed Sep 28 06:01:22 2005 From: kloch at hotnic.net (Kevin Loch) Date: Wed, 28 Sep 2005 06:01:22 -0400 Subject: [ppml] Policy Proposal 2005-1: Provider Independent IPv6 Assignments for End-sites - Revised Text In-Reply-To: References: Message-ID: <433A69F2.6060209@hotnic.net> Marshall Eubanks wrote: > I cannot support the current 2005-1 as I read it. I welcome attempts to convince me of the errors > of my ways. I ask that you reconsider supporting this as a framework for enabling end site assignments. It is important to note that the 100,000 device figure is not set in stone. According to the policy process it is possible to revise this figure if consensus can be reached at the next meeting. I encourage spirited discussion of the size (device) requirement here and at the meeting so we can get this right. - Kevin From tme at multicasttech.com Wed Sep 28 12:07:50 2005 From: tme at multicasttech.com (Marshall Eubanks) Date: Wed, 28 Sep 2005 12:07:50 -0400 Subject: [ppml] Policy Proposal 2005-1: Provider Independent IPv6 Assignments for End-sites - Revised Text In-Reply-To: <433A69F2.6060209@hotnic.net> Message-ID: On Wed, 28 Sep 2005 06:01:22 -0400 Kevin Loch wrote: > Marshall Eubanks wrote: > > I cannot support the current 2005-1 as I read it. I welcome attempts to convince me of the > errors > > of my ways. > > I ask that you reconsider supporting this as a framework for enabling > end site assignments. > On the basis of this and the similar arguments from Owen DeLong, I now support the current 2005-1. > It is important to note that the 100,000 device figure is not set in > stone. According to the policy process it is possible to revise this > figure if consensus can be reached at the next meeting. > > I encourage spirited discussion of the size (device) requirement here > and at the meeting so we can get this right. > > - Kevin Regards Marshall > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From marla_azinger at eli.net Wed Sep 28 12:12:13 2005 From: marla_azinger at eli.net (Azinger, Marla) Date: Wed, 28 Sep 2005 09:12:13 -0700 Subject: [ppml] Policy Proposal 2005-1: Provider Independent IPv6 Assignments for End-sites - Revised Text Message-ID: <10ECB7F03C568F48B9213EF9E7F790D2015124FB@wava00s2ke2k01.corp.pvt> Can someone who was involved with writing this proposal define the word "DEVICES". I ask because the debate that went on before was very interesting when it came to individual interpretations of what constitutes a "device" that should be allowed to use Public IP space. Thank you Marla Azinger Electric Lightwave -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Kevin Loch Sent: Wednesday, September 28, 2005 2:17 AM To: ppml at arin.net Subject: Re: [ppml] Policy Proposal 2005-1: Provider Independent IPv6 Assignments for End-sites - Revised Text Edward Lewis wrote: >> 4. be able to assign IPv6 addresses to at least 100,000 >>unique devices within 1 year and advertise that connectivity through >>it's single aggregated address assignment. > > > I'm curious about the rationale for "100,000." Not that I think it > is unreasonable, but was there any reason to pick that amount? > Perhaps something to do with the pain of renumbering? No precision is implied in that number. The rationale is that lower magnitudes might allow too many end sites to qualify for PI space. There is significant concern that policy mistakes made early on will have long lasting if not permanent effects on routing table size. 100,000 devices appeared to be a number that could overcome the opposition from the last meeting (as opposed to 10,000 for example). Personally I agree with Owen that 100,000 devices is absurdly high. I think a good target would be normalizing with IPv4 multihoming (~400 devices) or non multihoming (~1600 devices) requirements. But in the interest of getting the framework in place and at least some end site assignemnts made I agreed to put the device requirement in there. I made sure it was easy to reduce or eliminate the device requirement in the future without having to rewrite the rest of the section. - Kevin _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From steven.feldman at cnet.com Wed Sep 28 12:23:39 2005 From: steven.feldman at cnet.com (Steve Feldman) Date: Wed, 28 Sep 2005 09:23:39 -0700 Subject: [ppml] Policy Proposal 2005-1: Provider Independent IPv6 Assignments for End-sites - Revised Text In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D2015124FB@wava00s2ke2k01.corp.pvt> References: <10ECB7F03C568F48B9213EF9E7F790D2015124FB@wava00s2ke2k01.corp.pvt> Message-ID: <840937254920dfb8ce1f586d685c24b7@cnet.com> On Sep 28, 2005, at 9:12 AM, Azinger, Marla wrote: > Can someone who was involved with writing this proposal define the > word "DEVICES". I ask because the debate that went on before was very > interesting when it came to individual interpretations of what > constitutes a "device" that should be allowed to use Public IP space. Indeed. Assume for example that I have a pair of load balancers (one active, one standby) with 10 virtual IP addresses, and 100 physical hosts behind it. I could make an argument for this to be any of 1, 2, 10, 12, or 102 devices, and likely other amounts too. Steve From kloch at hotnic.net Wed Sep 28 13:57:16 2005 From: kloch at hotnic.net (Kevin Loch) Date: Wed, 28 Sep 2005 13:57:16 -0400 Subject: [ppml] Policy Proposal 2005-1: Provider Independent IPv6 Assignments for End-sites - Revised Text In-Reply-To: <840937254920dfb8ce1f586d685c24b7@cnet.com> References: <10ECB7F03C568F48B9213EF9E7F790D2015124FB@wava00s2ke2k01.corp.pvt> <840937254920dfb8ce1f586d685c24b7@cnet.com> Message-ID: <433AD97C.5070203@hotnic.net> Steve Feldman wrote: > On Sep 28, 2005, at 9:12 AM, Azinger, Marla wrote: > >>Can someone who was involved with writing this proposal define the >>word "DEVICES". I ask because the debate that went on before was very >>interesting when it came to individual interpretations of what >>constitutes a "device" that should be allowed to use Public IP space. > > Assume for example that I have a pair of load balancers (one active, > one standby) > with 10 virtual IP addresses, and 100 physical hosts behind it. > > I could make an argument for this to be any of 1, 2, 10, 12, or 102 > devices, > and likely other amounts too. It was my intent that each host, router, managed switch, rfid tag etc would count as one device regardless of the number of physical or virtual interfaces, or it's topological situation. In your example I would count 102 devices. - Kevin From memsvcs at arin.net Wed Sep 28 16:47:40 2005 From: memsvcs at arin.net (Member Services) Date: Wed, 28 Sep 2005 16:47:40 -0400 Subject: [ppml] WHOIS Display Modification Message-ID: <433B016C.1010803@arin.net> On Nov. 1, 2005, ARIN will be replacing the field labels for resource technical POCs in ARIN WHOIS in an effort to more visibly separate resource POCs from organization POCs. Resource technical POCs are associated only with an individual IP address or AS number range registration object. Organization POCs are associated with the OrgID object and with all numbering resource registration objects associated with the OrgID. The field labels for resource technical POCs currently are displayed as: TechHandle: ARIN-HOSTMASTER TechName: Registration Services Department TechPhone: +1-703-227-0660 TechEmail: hostmaster at arin.net After the change, resource technical POCs will display as: RTechHandle: ARIN-HOSTMASTER RTechName: Registration Services Department RTechPhone: +1-703-227-0660 RTechEmail: hostmaster at arin.net For further questions, please contact hostmaster at arin.net. Regards, Leslie Nobile Director, Registration Services American Registry for Internet Numbers (ARIN) From memsvcs at arin.net Thu Sep 29 11:52:55 2005 From: memsvcs at arin.net (Member Services) Date: Thu, 29 Sep 2005 11:52:55 -0400 Subject: [ppml] Join Us in Los Angeles for ARIN XVI! Message-ID: <433C0DD7.1010408@arin.net> Have you made your arrangements yet to attend ARIN XVI, which will be held back-to-back with NANOG 35, at the Hilton Los Angeles / Universal City in Los Angeles, CA? The ARIN XVI Public Policy and Members Meeting will take place from October 26-28, 2005, and NANOG 35 will take place from October 23-25, 2005. This meeting will also feature an ARIN and NANOG joint workshop, titled "Getting Started with IPv6," this will provide technical, hands-on guidance in setting up IPv6 on your own laptop and practical instruction on the basics of implementing IPv6. The workshop is targeted at engineers and network administrators from both ISPs and SOHO/Enterprise networks. Participants should already have a basic knowledge of IPv6. REGISTER NOW! Doing so allows you to take advantage of this unique and special opportunity. In addition to the packed meeting agenda, there will be tutorials, the Open Policy Hour, a great social at the Lucky Strike Lanes bowling alley, and terrific opportunities for networking with colleagues throughout the meeting. Register and reserve your hotel room before October 8 to take advantage of the special meeting attendee rate of $128 a night! Registration, detailed meeting and hotel information, and everything ARIN XVI-related is available at: http://www.arin.net/ARIN-XVI/ Agenda information is updated periodically, so do not forget to check back. If you need any assistance or have questions, please contact us at memsvcs at arin.net. See you soon in Los Angeles! Regards, Member Services Department American Registry for Internet Numbers =================================================================== E-mail memsvcs at arin.net FTP ftp.arin.net WHOIS whois.arin.net Website http://www.arin.net =================================================================== From hannigan at verisign.com Fri Sep 30 02:30:54 2005 From: hannigan at verisign.com (Hannigan, Martin) Date: Fri, 30 Sep 2005 02:30:54 -0400 Subject: [ppml] Policy Proposal 2005-1: Provider Independent IPv6 Assignments for End-sites - Revised Text Message-ID: > > There is just too much religion about not giving PI space to "small" > organizations > to achieve consensus around the original 2005-1. Between the AC > representatives > that worked with us, Kevin (who authored another similar > policy which was > merged > with 2005-1), and myself, we decided that this was the best > way to go to > achieve > consensus and get a policy on the books. > Policy statement Add new subsection to the NRPM: d. must be able to assign IPv6 addresses to at least 100,000 unique devices within 1 year and advertise that connectivity through it's single aggregated address assignment. I support the policy for the most part and I would like to say so publicly. I don't have an issue with the device count in terms of how it's applied in the rationale, but I wonder if you might not consider extending the time frame of assignment to 2 years instead of futzing the device count since it seems that this may be the focus? Using the most conservative count I can think of, I found it difficult to execute something this large, even as an SP, in one year. I also imagined myself standing up in front of the funding commitee explaining why I only had a year and I felt I may be unable to justify it in 1 year. The rationale is to be conservative, but holding this to only the Fortune 10 and cellular carriers seems to be slightly tilted towards detrimental to the adaptation and use of IPV6. Thank you! Martin From kloch at hotnic.net Fri Sep 30 15:20:22 2005 From: kloch at hotnic.net (Kevin Loch) Date: Fri, 30 Sep 2005 15:20:22 -0400 Subject: [ppml] Policy Proposal 2005-1: Provider Independent IPv6 Assignments for End-sites - Revised Text In-Reply-To: References: Message-ID: <433D8FF6.7010304@hotnic.net> Hannigan, Martin wrote: > I support the policy for the most part and I would like to say > so publicly. I don't have an issue with the device count in > terms of how it's applied in the rationale, but I wonder if you > might not consider extending the time frame of assignment to 2 > years instead of futzing the device count since it seems that this > may be the focus? Using the most conservative count I can > think of, I found it difficult to execute something this large, even > as an SP, in one year. I also imagined myself standing up in front > of the funding commitee explaining why I only had a year > and I felt I may be unable to justify it in 1 year. The intent was that the applying organization has 100,000 capable devices at the time of the application, or would have them credibly within one year. In no way does it require you to actually complete assignment of 100,000 address in one year. > The rationale is to be conservative, but holding this to only the > Fortune 10 and cellular carriers seems to be slightly tilted towards > detrimental to the adaptation and use of IPV6. I agree. what number would you pick to balance conservation with encouraging deployment? - Kevin From hannigan at verisign.com Fri Sep 30 16:55:24 2005 From: hannigan at verisign.com (Hannigan, Martin) Date: Fri, 30 Sep 2005 16:55:24 -0400 Subject: [ppml] Policy Proposal 2005-1: Provider Independent IPv6 Assignments for End-sites - Revised Text Message-ID: Hi Kevin: > Hannigan, Martin wrote: > > I support the policy for the most part and I would like to say > > so publicly. I don't have an issue with the device count in > > terms of how it's applied in the rationale, but I wonder if you > > might not consider extending the time frame of assignment to 2 > > years instead of futzing the device count since it seems that this > > may be the focus? Using the most conservative count I can > > think of, I found it difficult to execute something this > large, even > > as an SP, in one year. I also imagined myself standing up in front > > of the funding commitee explaining why I only had a year > > and I felt I may be unable to justify it in 1 year. > > The intent was that the applying organization has 100,000 capable > devices at the time of the application, or would have them > credibly within one year. In no way does it require you to actually > complete assignment of 100,000 address in one year. > Understood. I'm working from the "have nots" side for further clarification. > > The rationale is to be conservative, but holding this to only the > > Fortune 10 and cellular carriers seems to be slightly > tilted towards > > detrimental to the adaptation and use of IPV6. > > I agree. what number would you pick to balance conservation > with encouraging deployment? 25,000 x 2 years. I agree with you both that starting at the high end makes sense and for all intents and purposes I think this is the lower side of the high end. My reasoning on the year adjustment is that it's a simpler redefinement than device count to gain a squeeze if needed. Thank you! -M< From stephen at sprunk.org Fri Sep 30 17:18:52 2005 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 30 Sep 2005 16:18:52 -0500 Subject: [ppml] Policy Proposal 2005-1: Provider Independent IPv6 Assignments for End-sites - Revised Text References: <433D8FF6.7010304@hotnic.net> Message-ID: <01e001c5c607$63706c30$6501a8c0@dax> Thus spake "Kevin Loch" > Hannigan, Martin wrote: >> The rationale is to be conservative, but holding this to only the >> Fortune 10 and cellular carriers seems to be slightly tilted towards >> detrimental to the adaptation and use of IPV6. > > I agree. what number would you pick to balance conservation > with encouraging deployment? My two cents: the lowest possible number that will still get approval. Martin's 25k/2yrs sounds much more reasonable than 100k/1yr, and I would hope others here would back that. Could we go even lower safely? I'm not sure. Does anyone have any stats on the number of ISPs and businesses that would qualify at various levels? S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov