From info at arin.net Wed Apr 11 13:55:47 2007 From: info at arin.net (Member Services) Date: Wed, 11 Apr 2007 13:55:47 -0400 Subject: ARIN XIX - Open Policy Hour Message-ID: <461D2123.5010802@arin.net> Some Questions About the Policy Process 1. Do you want to know what policy proposals will be discussed at the upcoming ARIN Public Policy Meeting? 2. Do you have an idea about how ARIN should manage Internet Number Resources? 3. Do you think that a current policy should be enhanced or changed, or even retired? 4. Are you hesitant about making a formal proposal on the Public Policy Mail List (PPML)? 5. 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 get a better understanding of what is going to be discussed at the upcoming Public Policy Meeting or for you to discuss your ideas in an open, informal forum and receive feedback or both! The Open Policy Hour consists of two parts. Part One is the P2B2 or the Policy Proposal Background Briefing. ARIN staff will provide summary information regarding the policy proposals that will be discussed at the meeting. Members of the ARIN Advisory Council will be present to answer general questions about the policy proposals. There will be no discussion of the proposals, just the information that you need to help you understand the nature of the proposals. ARIN staff will also provide a Policy Evaluation and Feedback Report. This report provides a staff evaluation of current ARIN policies, based on the experience gained by the staff in policy implementation and application, as well as feedback provided by ARIN customers. Part Two is the P2B or the Policy Proposal BoF. This is where you get a chance to "test drive" a policy idea. How can you participate? Bring your ideas and questions. If you have a policy suggestion 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 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 18 April 2007 with your name, organization, and a brief description of your policy subject. Come join your colleagues in this informal setting. The Open Policy Hour for ARIN XIX will be held on Sunday, 22 April, from 4:30 - 6:00 PM. If you are not familiar with the way policies are developed in the ARIN region, join ARIN staff a half hour earlier, at 4:00 PM, for a review of the Internet Resource Policy Evaluation Process. Registration information for ARIN XIX is available at: http://www.arin.net/ARIN-XIX/ Contact Member Services at info at arin.net if you have any questions. Regards, Member Services Department American Registry for Internet Numbers From info at arin.net Fri Apr 13 10:34:34 2007 From: info at arin.net (Member Services) Date: Fri, 13 Apr 2007 10:34:34 -0400 Subject: Policy Proposal 2007-2 - Staff Assessment Message-ID: <461F94FA.4030708@arin.net> Policy Proposal 2007-2 Documentation of the Mail-From Authentication Method ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal 2007-2 is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_2.html II. Understanding of the proposal ARIN staff understands that this proposal would define mail-from as the default authentication; it relies on the adoption of Policy Proposal 2007-1: Reinstatement of PGP Authentication Method. III. Issues and concerns A. ARIN Staff 1. Mail-from is the default authentication method by which e-mail communication is evaluated to determine authenticity of the message and identity of the sender. It is not used to protect against "vandalism". Even an authenticated user can vandalize, i.e. with inappropriate comments or with ASCII art. 2. We recommend that a new NRPM section be created, ?12. Communications? and that 12.1 be ?Authentication?. The subsequent numbering would change appropriately. B. ARIN General Counsel The policy as proposed poses no significant legal risks for ARIN. IV. Resource Impact - Minimum The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. However, implementation will depend on the outcome of Policy Proposal 2007-1: Reinstatement of PGP Authentication Method. Implementation would not require the acquisition of staff personnel or equipment. It will require the following: - Revisions to registration guidelines - Staff Training Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-2 Documentation of the Mail-From Authentication Method Proposal type: New Policy term: Permanent Policy statement: DELETION FROM THE NRPM 12.1 Mail-From This section intentionally left blank. ADDITION TO THE NRPM 12.1 Mail-From Mail-From is the default authentication method by which registration records are protected from vandalism. If a registrant fails to designate a more secure method, any subsequent email which bears the sender address of an authorized Point of Contact may be deemed authentic with regard to the registrant's records. Since it is trivial to forge a sender address, Mail-From should not be regarded as secure. Use of Mail-From authentication is not recommended to any registrant who has the means to implement either of the more secure cryptographic authentication methods. Rationale: This policy complements the previously-proposed "Reinstatement of PGP Authentication Method" which introduces section 12 to the NRPM. Section 12 relates the existence of three authentication methods. Two of those, mail-from and X.509, were preexisting but not documented within the NRPM. This policy proposal simply seeks to provide brief documentation of the existence of the mail-from authentication method. Because the specific wording of the documentation may be subject to debate, and is in no way interdependent upon the documentation of the other two methods, it is being proposed in a separate policy, so that consensus may be more easily reached. Timetable for implementation: Immediate From info at arin.net Fri Apr 13 10:34:55 2007 From: info at arin.net (Member Services) Date: Fri, 13 Apr 2007 10:34:55 -0400 Subject: Policy Proposal 2007-3 - Staff Assessment Message-ID: <461F950F.2020605@arin.net> Policy Proposal 2007-3 Documentation of the X.509 Authentication Method ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal 2007-3 is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_3.html II. Understanding of the proposal ARIN staff understands that this proposal would support X.509 authentication; it relies on the adoption of Policy Proposal 2007-1: Reinstatement of PGP Authentication Method. III. Issues and concerns A. ARIN Staff 1. Proposals use the term "crypt-auth", term needs to be defined. Also, would need specific notation, such as crypt-pgp and crypt-x509. 2. "Accepts X.509 signed transactions as authentic communications from authorized POCs" - this needs clarification. What certification sources should be considered when accepting X.509 certificates? 3. NRPM section 12.3 contains procedural language which constrains ARIN's ability to act in the best interest of all parties. It is too restrictive and detailed. 4. At this time, ARIN?s functionality covers only e-mail based communication. The policy uses the general term, ?communication?, which may be interpreted to cover other forms of electronic interaction such as web-based communication. The only other ?communication? that is directly tied into a specific POC is voting. Should the Election System need to be modified to allow x.509 authentication, assuming we could use parts of the existing system, a ballpark estimate on implementation would be 3-4 months. 5. We recommend that a new NRPM section be created, ?12. Communications? and that 12.1 be ?Authentication?. The subsequent numbering would change appropriately. B. ARIN General Counsel The policy as proposed poses no significant legal risks for ARIN. IV. Resource Impact - Minimum The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 120 days from the date of the ratification of the policy by the ARIN Board of Trustees. However, implementation will depend on the outcome of Policy Proposal 2007-1: Reinstatement of PGP Authentication Method. Implementation would not require the acquisition of staff personnel or equipment. It will require the following: - Revisions to registration guidelines - Staff Training Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-3 Documentation of the X.509 Authentication Method Policy statement Proposal type: New Policy term: Permanent Policy statement: DELETION FROM THE NRPM 12.3 X.509 This section intentionally left blank. ADDITION TO THE NRPM 12.3 X.509 ARIN accepts X.509-signed transactions as authentic communication from authorized Points of Contact. POCs may denote their records "crypt-auth," subsequent to which unsigned communications shall not be deemed authentic with regard to those records. Rationale: This policy complements the previously-proposed "Reinstatement of PGP Authentication Method" which introduces section 12 to the NRPM. Section 12 relates the existence of three authentication methods. Two of those, mail-from and X.509, were preexisting but not documented within the NRPM. This policy proposal simply seeks to provide brief documentation of the existence of the X.509 authentication method. Because the specific wording of the documentation may be subject to debate, and is in no way interdependent upon the documentation of the other two methods, it is being proposed in a separate policy, so that consensus may be more easily reached. Timetable for implementation: Immediate From info at arin.net Fri Apr 13 10:35:08 2007 From: info at arin.net (Member Services) Date: Fri, 13 Apr 2007 10:35:08 -0400 Subject: Policy Proposal 2007-4 - Staff Assessment Message-ID: <461F951C.6080104@arin.net> Policy Proposal 2007-4 Changes to IPv6 policy - removal of "interim" consideration ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal 2007-4 is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_4.html II. Understanding of the proposal ARIN staff understands that this proposal would remove the sentence that refers to IPv6 policy as interim policy. III. Issues and concerns A. ARIN Staff No comments at this time. B. ARIN General Counsel The policy as proposed poses no significant legal risks for ARIN. IV. Resource Impact - Minimum The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. Implementation would not require the acquisition of staff personnel or equipment. It will require the following: - Revisions to registration guidelines - Staff Training Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-4 Changes to IPv6 policy - removal of "interim" consideration Proposal type: delete Policy term: permanent Policy statement: Delete following text at section 6.1.1 of NRPM: "This policy is considered to be an interim policy. It will be reviewed in the future, subject to greater experience in the administration of IPv6." Rationale: The actual text suggest that it is an interim policy, however it is not longer the case. It is clear that any policy is always subjected to changes, however other policies don't have such text. It may be even considered as a negative "message" for IPv6 deployment, especially because the possible "reading" as "not enough experience and this is going to be changed, better wait", which is not a real situation. No financial/liability implications for the community and ARIN are foreseen. No special conditions, fees, exceptions, etc. seem to be required. Timetable for implementation: Immediate From info at arin.net Fri Apr 13 10:35:17 2007 From: info at arin.net (Member Services) Date: Fri, 13 Apr 2007 10:35:17 -0400 Subject: Policy Proposal 2007-5 - Staff Assessment Message-ID: <461F9525.2030406@arin.net> Policy Proposal 2007-5 Changes to IPv6 policy - removal of "multiple /48" justification ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal 2007-5 is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_5.html II. Understanding of the proposal Current policy is that ISPs are required to obtain approval from ARIN when assigning an additional /48 to a single site. ARIN staff understands that this proposal would remove that policy. III. Issues and concerns A. ARIN Staff 1. ARIN has not yet seen or reviewed any requests for additional or subsequent assignments to the same end site. 2. The existing policy text is confusing and might indicate to some that even initial assignments of more than a /48 would need to be reviewed by staff. However, we have not done this and have allowed larger than /48 reassignments to be processed. 3. In addition, the policy text contains no criteria for ARIN to use in their assessment of assignments larger than /48. B. ARIN General Counsel This policy as proposed poses no significant legal risks for ARIN. IV. Resource Impact - Minimum The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. Implementation would not require the acquisition of staff personnel or equipment. It will require the following: - Template change - Minor update to software - Revisions to registration guidelines - Staff Training Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-5 Changes to IPv6 policy - removal of "multiple /48" justification Proposal type: delete Policy term: permanent Policy statement: Delete section 6.5.4.2 of NRPM. Rationale: The current text requires the LIR to justify to the RIR/NIR when assigning multiple /48s to a single end site. It seems that the reason for this requirement is the lack of experience, which seems unreasonable after a few years this policy has been implemented, even if may not have been specific cases which used this policy section. It seems useless, now that there is already deployment experience, to require a justification from the LIR to ARIN for assigning multiple /48s (or a shorter prefix, such as for example a /47). It is up to the LIR to require the justification to its own customers and decide according to it. The LIR will be already responsible to justify to ARIN the usage of any allocated block(s) when requesting for more, and this will already implicate an implicit justification of this kind of assignments. With this policy change, both ARIN and LIR staff will save resources in a justification, which seems unnecessary and should be completely on the hands of the LIR itself. No financial/liability implications for the community and ARIN are foreseen. No special conditions, fees, exceptions, etc. seem to be required. Timetable for implementation: Immediate From info at arin.net Fri Apr 13 10:35:27 2007 From: info at arin.net (Member Services) Date: Fri, 13 Apr 2007 10:35:27 -0400 Subject: Policy Proposal 2007-7 - Staff Assessment Message-ID: <461F952F.3070400@arin.net> Policy Proposal 2007-7 Creation of Policy for Subsequent End-User IP Requests/Assignments ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal 2007-7 is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_7.html II. Understanding of the proposal ARIN staff understands that this proposal would establish the criteria for subsequent end-user IPv4 address space requests. III. Issues and concerns A. ARIN Staff No comments at this time. B. ARIN General Counsel The policy as proposed poses no significant legal risks for ARIN. We also believe that it is useful to be specific in the manner articulated by the proposed policy. IV. Resource Impact - Minimum The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. Implementation would not require the acquisition of staff personnel or equipment. It will require the following: - Revisions to registration guidelines - Staff Training Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-7 Creation of Policy for Subsequent End-User IP Requests/Assignments Proposal type: New Policy term: Permanent Policy statement: 4.3.6 Additional Assignments "In order to justify an additional assignment, end-users must have efficiently utilized at least 80% of all previous assignments, and must provide ARIN with utilization details. The prefix size for an additional assignment is determined by applying policies 4.3.2, and 4.3.3." Rationale: There are no published criteria for additional assignment requests from end-user networks. NRPM 4.3 seems to only cover initial assignments. NRPM 4.3.3 states, in part, "Requesters must show exactly how previous address assignments have been utilized and must provide appropriate details to verify their one-year growth projection." Unfortunately, the above text does not specify any metrics for ARIN staff to apply when determining if an additional assignment is justified. Though most end-users only get one assignment, some end-users request a 2nd or 3rd or Nth assignment. Currently, the ARIN staff applies what they perceive to be "efficient utilization" criteria; for instance, the end-user must have utilized at least 80% of last assignment and must provide ARIN with utilization details. Timetable for implementation: Immediate From info at arin.net Fri Apr 13 10:35:38 2007 From: info at arin.net (Member Services) Date: Fri, 13 Apr 2007 10:35:38 -0400 Subject: Policy Proposal 2007-8 - Staff Assessment Message-ID: <461F953A.8000503@arin.net> Policy Proposal 2007-8 Transfer Policy Clarifications ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal 2007-8 is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_8.html II. Understanding of the proposal ARIN staff understands that this proposal would standardize the use of the term "number resources" throughout the transfer section of the NRPM. III. Issues and concerns A. ARIN Staff No comments at this time. B. ARIN General Counsel The ARIN General Counsel stated, "We are reviewing this policy. In the past, we have advised that transfer issues create the risk of litigation when ARIN refuses to transfer resources. In view of the non-uniform RSAs, including some that have different dispute mechanisms, ARIN should handle any changes regarding transfer as a policy, rather than amending the RSA. ARIN should consider amending the proposed policy so as to provide, in sum or substance, that if a party does not obtain the transferred resources within a certain period of time, e.g., 30 days or 45 days, then it would have the right to initiate a dispute in the forum specified under the current RSA or the RSA that governs the party." IV. Resource Impact - Minimum The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. Implementation would not require the acquisition of staff personnel or equipment. It will require the following: - Revisions to registration guidelines - Staff Training Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-8 Transfer Policy Clarifications Proposal type: Modify Policy term: Permanent Policy statement: That Section 8 of the NRPM is replaced as follows: 8. Transfers 8.1. Transfers Number resources are non-transferable and are not assignable to any other organization unless ARIN has expressly and in writing approved a request for transfer. ARIN is tasked with making prudent decisions on whether to approve the transfer of number resources. It should be understood that number resources are not "sold" under ARIN administration. Rather, number resources are assigned to an organization for its exclusive use for the purpose stated in the request, provided the terms of the Registration Services Agreement continue to be met and the stated purpose for the number resources remains the same. Number resources are administered and assigned according to ARIN's published policies. Number resources are issued, based on justified need, to organizations, not to individuals representing those organizations. Thus, if a company goes out of business, regardless of the reason, the point of contact (POC) listed for the number resource does not have the authority to sell, transfer, assign, or give the number resource to any other person or organization. The POC must notify ARIN if a business fails so the assigned number resources can be returned to the available pool of number resources if a transfer is not requested and justified. 8.2. Transfer Requirements ARIN will consider requests for the transfer of number resources only upon receipt of evidence that the new entity has acquired the assets which had, as of the date of the acquisition or proposed reorganization, justified the current entity's use of the number resource. Examples of assets that justify use of the number resource include, but are not limited to: * Existing customer base * Qualified hardware inventory * Specific software requirements. 8.3. Documentation Requirements In evaluating a request for transfer, ARIN may require the requesting organization to provide any of the following documents, as applicable, plus any other documents deemed appropriate: * An authenticated copy of the instrument(s) effecting the transfer of assets, e.g., bill of sale, certificate of merger, contract, deed, or court decree * A detailed inventory of all assets utilized by the requesting party in maintaining and using the number resource * A list of the requesting party's customers using the number resources If further justification is required, the requesting party may be asked to provide any of the following, or other supporting documentation, as applicable: * A general listing of the assets or components acquired * A specific description of acquisitions, including: o Type and quantity of equipment o Customer base * A description of how address space is being utilized * Network engineering plans, including: o Host counts o Subnet masking o Network diagrams o Reassignments to customers Policy Rationale Staff analysis and community comments have a problem with the inconsistent use of the terms "ASN" and "IP Address" in this section which leads to confusion on which resources can be transferred. The entire section now utilizes the term "number resources" to clarify what would appear to be the original intent. A section regarding the handling of customer networks outside ARIN's geographic region has been removed to reflect the actual current procedure utilized that was developed in conjunction with the ERX transfer project. The last section of old text has been removed as it does not appear to be so much policy as guidance. Timetable for implementation: Immediate From info at arin.net Fri Apr 13 10:35:48 2007 From: info at arin.net (Member Services) Date: Fri, 13 Apr 2007 10:35:48 -0400 Subject: Policy Proposal 2007-11 - Staff Assessment Message-ID: <461F9544.4070600@arin.net> Policy Proposal 2007-11 Refinement of ISP Initial Allocation Policy ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal 2007-11 is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_11.html II. Understanding of the proposal ARIN staff understands that this proposal would remove a sentence which refers to completing a template. III. Issues and concerns A. ARIN Staff No comments at this time. B. ARIN General Counsel The policy as proposed poses no significant legal risks for ARIN. IV. Resource Impact - Minimum The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. Implementation would not require the acquisition of staff personnel or equipment. It will require the following: - Revisions to registration guidelines - Staff Training Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-11 Refinement of ISP Initial Allocation Policy Policy statement Proposal type: modify Policy term: permanent Policy statement: In NRPM 4.2.4.3 (Initial Allocations to ISPs Policy), strike the following sentence: "When completing Section 7 of the ARIN ISP Network Request Template, please keep this in mind" Rationale: Instructions on filling out templates properly belong in the instructions attached to the template, not as part of a policy statement. This reminder makes reference to an obsolete template and section. ARIN released new templates in August 2006 and changed template names, field numbers, and sections which made both of these references obsolete. Timetable for implementation: Immediate From info at arin.net Fri Apr 13 14:21:49 2007 From: info at arin.net (Member Services) Date: Fri, 13 Apr 2007 14:21:49 -0400 Subject: Policy Proposal 2007-6 - Staff Assessment Message-ID: <461FCA3D.2030400@arin.net> Policy Proposal 2007-6 IPv4 PI minimum size change ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal 2007-6 is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_6.html II. Understanding of the proposal ARIN staff understands that this proposal would reduce the minimum assignment for multihomed end-users from a /22 to a /24 IPv4 address block. III. Issues and concerns A. ARIN Staff 1. There is very little qualification criteria which could lead to policy abuse by spammers. These entities could create many different accounts over time as their existing space gets blacklisted or becomes otherwise unusable. 2. This could significantly increase the number of requests for ARIN services thereby requiring additional Registration Services Department and Financial Services Department staff. 3. Policy applies only to end users which could be perceived as unfair to ISPs. This could also lead to potential abuse of the policy if ISPs apply as end users for single /24 IPv4 address block. 4. It is unclear exactly how an organization can qualify for a /24 IPv4 address block under this policy. It appears that NRPM section 4.3.3, Utilization rate, requires 25% immediate, 50% within 1 year, would be the justification criteria. However, NRPM section 4.2.3.6, Reassignments to multihomed downstream customers, indicates that an ISP can reassign a /24 IPv4 address block without regard to planned host counts as long as the customer is multi-homed. The question here is does this policy allow ARIN to qualify a requestor for a /24 IPv4 address block based solely on multi-homing or should host counts also be taken into account? 5. The policy does not address requests for more than one /24 IPv4 address block for multiple sites. 6. NRPM Section 4.4, Micro-allocation, should remain as is since it is a policy section essential for micro-allocation for critical infrastructure related requests. B. ARIN General Counsel The policy as proposed poses no significant legal risks for ARIN. IV. Resource Impact - Minimum The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. Implementation might require the acquisition of staff personnel or equipment. It will require the following: - Minor update to software - Revisions to registration guidelines - Staff Training Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-6 IPv4 PI minimum size change Proposal type: modify Policy term: permanent Policy statement: In section 4.3.2.2 of the NRPM, change all occurences of "/22" to "/24". (That is, replace the existing 4.3.2.2 with this text: For end-users who demonstrate an intent to announce the requested space in a multihomed fashion, the minimum block of IP address space assigned is a /24. If assignments smaller than a /24 are needed, multihomed end-users should contact their upstream providers. When prefixes are assigned which are longer than /20, they will be from a block reserved for that purpose.) Remove references to IPv4 in section 4.4, as they are no longer relevant. Section 4.4 could be moved, at the discretion of the NRPM editors, to somewhere in section 6, for clarity. Rationale: The rationale for moving the allocation "edge" for IPv4 PI space to /24 has three fundamental points: routing slot consumption would be unchanged, it reflects widespread routing practices, and it discourages waste. While experiments indicate that a few ISPs still try to filter at the /22 boundary, I have been repeatedly told that most don't filter anything shorter than a /24. While routing policy and allocation policies don't need to necessarily match, it is not unreasonable to have them in alignment. In addition, by keeping the PI allocation size for multi-homed organizations at /22, organizations seeking PI space that don't meet the requirements may be encouraged to exaggerate their address usage. This is something that should clearly not be encouraged. On the topic of routing slots, I would like to note that any org qualifying under the PI policies in 4.3.2.2 would also qualify for PA space, and would likely have an interest in multi-homing regardless of the usage of PA vs. PI space. In either instance, a routing slot is consumed by a /24. This policy change should therefore have minimal, if any, impact on the size of the global routing table. It merely gives organizations more options at a slightly smaller network size. Remember that for consideration under 4.3.2.2, an organiztion *must* be multi-homed. On a side note, it's tempting to remove the restriction entirely. If an organization only qualifies for a /28 (for example), they could receive an allocation of that size. Market forces would decide if that /28 was worth a routing slot. If the /28 contained my personal website, I suspect it would not be routable. If that /28 contained Microsoft Update, I suspect it would. In the interest of operational sanity and simplicity, I am not making a proposal to remove the restriction. (Note that section 4.1.1 explicitly notes that PI addresses are not guaranteed to be globally routable.) There is fundamental conflict between the urge for aggregation and the desire for conservation. The latter would prefer that organizations not have any excess space, while the former would prefer that fewer networks exist in the DFZ, regardless of wastage. Since the DFZ already permits deaggregation to /24, the conservation urge should be allowed to push to that edge. As noted in 4.1.5, "determination of IP address allocation size is the responsibility of ARIN." This proposal simply allows the community to request appropriately sized blocks, and ARIN to allocate prefixes of a size that is commensurate with established need. Timetable for implementation: immediate From info at arin.net Fri Apr 13 14:21:59 2007 From: info at arin.net (Member Services) Date: Fri, 13 Apr 2007 14:21:59 -0400 Subject: Policy Proposal 2007-9 - Staff Assessment Message-ID: <461FCA47.8040608@arin.net> Policy Proposal 2007-9 Modernization of ISP Immediate Need Policy ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal 2007-9 is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_9.html II. Understanding of the proposal ARIN staff understands this proposal would change the immediate need policy by reducing the minimum allocation from a fixed /20 IPv4 address block to ARIN?s current minimum allocation as defined elsewhere in the NRPM, and would set the maximum allocation size at a /16 IPv4 address block. The policy also defines a 30 day utilization window of the IP address space. III. Issues and concerns A. ARIN Staff No comments at this time. B. ARIN General Counsel The policy as proposed poses no significant legal risks for ARIN. We also believe that this policy is beneficial because it prevents the waste of resources. IV. Resource Impact - Minimum The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. Implementation would not require the acquisition of staff personnel or equipment. It will require the following: - Revisions to registration guidelines - Staff Training Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-9 Modernization of ISP Immediate Need Policy Proposal type: modify Policy term: permanent Policy statement: Modify NRPM 4.2.1.6 to read: If an ISP has an immediate need for address space, and can provide justification to show that the address space will be utilized within 30 days of the request, ARIN may issue a block of address space, not larger than a /16 nor smaller than ARIN's customary minimum allocation, to that organization. These cases are exceptional. Current text of 4.2.1.6: If an ISP has an immediate need for address space, i.e., the need exists the day of the request, ARIN may issue a /20 if the organization, such as a new company, shows justification. However, these cases are exceptional. Rationale: ARIN staff and ARIN members have identified a few long-standing problems with the Immediate Need policy. This policy proposal attempts to address the following concerns: * The Immediate Need policy only allows ISPs to qualify for a /20 worth of space, when a larger size block may be necessary to provide proper coverage for the proposed project. An example justifying larger space is an MSOs for which a /20 is insufficient to put an address block larger than a /29 or /30 on each CMTS in a metropolitan area). * Conversely, this policy was written before the current multi-homed policy (which allows allocations of /21s and /22s). The Immediate Need policy should allow assignment of smaller blocks of space if those are justified. * The example used in the Immediate Need policy gives the impression that an immediate need must exist the day of the request. This seems both unfair and unreasonable and should probably be changed to reflect a realistic timeframe. Concerns expressed about the Immediate Need Policy but NOT addressed by this policy proposal (but addressed in a subsequent policy proposal): * The policy as written allows ARIN to issue a /20 to an ISP only. However, section 4.3.4. "Additional Considerations" of the End User Policy in the NRPM states that "End-users may qualify for address space under other policies such as Immediate need [4.2.1.6] or Micro-allocation [4.4].". In order to be consistent, the Immediate Need policy language should be changed to reflect the fact that both ISPs and end-users can qualify under this policy. Timetable for implementation: Immediate From info at arin.net Fri Apr 13 14:22:09 2007 From: info at arin.net (Member Services) Date: Fri, 13 Apr 2007 14:22:09 -0400 Subject: Policy Proposal 2007-10 - Staff Assessment Message-ID: <461FCA51.1080108@arin.net> Policy Proposal 2007-10 End Site Immediate Need Policy ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal 2007-10 is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_10.html II. Understanding of the proposal ARIN staff understands that if Policy Proposal 2007-9: Modernization of ISP Immediate Need is adopted, then Policy Proposal 2007-10: End Site Immediate Need Policy would establish the immediate need policy for end-users. The minimum assignment would be the ARIN?s minimum assignment as defined elsewhere in the NRPM, and the maximum would be a /16 IPv4 address block. The policy also defines a 30 day utilization window of the IP address space. If Policy Proposal 2007-9: Modernization of ISP Immediate Need is not adopted, then Policy Proposal 2007-10: End Site Immediate Need would require replicating the text from the existing ISP Immediate Need policy into the end user section of NRPM. III. Issues and concerns A. ARIN Staff Text should have 'allocation' changed to 'assignment' because this refers to end-user assignments. B. ARIN General Counsel The policy as proposed poses no significant legal risks for ARIN. We also believe that this policy is beneficial because it treats categories of applicants equally. IV. Resource Impact - Minimum The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. Implementation would not require the acquisition of staff personnel or equipment. It will require the following: - Revisions to registration guidelines - Staff Training Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-10 End Site Immediate Need Policy Proposal type: new Policy term: permanent Policy statement: Create new section in NRPM 4.3.6. to mirror the intent of 4.2.1.6, but modified for end sites. If pending proposal "Modernization of ISP Immediate Need Policy" is ratified, this new section will read: 4.3.6 Immediate Need: If an end-user has an immediate need for address space, and can provide justification to show that the address space will be utilized within 30 days of the request, ARIN may issue a block of address space, not larger than a /16 nor smaller than ARIN's customary minimum allocation, to that organization. These cases are exceptional. In the absence of ratification of ""Modernization of ISP Immediate Need Policy", this proposal is to add section 4.3.6 with a modification of the current text of 4.2.1.6 to make it apply to end-users: 4.3.6 Immediate Need: If an end-user has an immediate need for address space, i.e., the need exists the day of the request, ARIN may issue a /20 if the organization, such as a new company, shows justification. However, these cases are exceptional. Rationale: ARIN staff has expressed the concern that the current policy is self-contradictory, in one place stating that the Immediate Need Policy applies to ISPs, and in another place stating that end users can qualify under it. The communication received was: * The policy as written allows ARIN to issue a /20 to an ISP only. However, section 4.3.4. "Additional Considerations" of the End User Policy in the NRPM states that "End-users may qualify for address space under other policies such as Immediate need [4.2.1.6] or Micro-allocation [4.4].". In order to be consistent, the Immediate Need policy language should be changed to reflect the fact that both ISPs and end-users can qualify under this policy. Timetable for implementation: Immediate From info at arin.net Fri Apr 13 14:22:19 2007 From: info at arin.net (Member Services) Date: Fri, 13 Apr 2007 14:22:19 -0400 Subject: Policy Proposal 2007-1 - Staff Assessment Message-ID: <461FCA5B.90109@arin.net> Policy Proposal 2007-1 Reinstatement of PGP Authentication Method ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal 2007-1 is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_1.html II. Understanding of the proposal ARIN staff understands this proposal would support PGP authentication. III. Issues and concerns A. ARIN Staff 1. We recommend that a new NRPM section be created, "12. Communications", and that 12.1 be "Authentication". The subsequent numbering would change appropriately. 2. The proposal uses the term "crypt-auth" as a notation to be affixed to POC records. Such notation is not technically necessary for ARIN systems to discern authentication methods, because mere existence of a stronger-authentication method than mail-from can (and currently does) automatically disable mail-from authentication. 3. Staff believes that there was a formatting problem with the policy submission. It appears that the authors inadvertently incorporated procedural text under the headings "UPDATES TO TEMPLATES", "UPDATES TO DOCUMENTATION", and "KEY USE IN COMMUNICATION" under the policy text labeled "12.3 X.509: This section intentionally left blank.? If passed without edit, such procedural text could be incorporated into the NRPM. Staff suspects this was not the author's intent, as these headings and their subsequent text are not numbered. 4. In the section "KEY USE IN COMMUNICATION", the proposal requires validation of "a chain of trust not longer than five steps" between the signing key and ARIN's hostmaster role key, without regard to whether such intermediary signers are ARIN POCs, or are even known to ARIN. Without direct binding of the PGP key to an ARIN POC record, such anonymity in the chain of trust raises serious questions about how ARIN staff will know and evaluate that an e-mail from a signer is authentically from the ARIN POC that the sender claims to be. 5. A PGP-key for hostmaster at arin.net exists on pgp.mit.edu as well as other well-known PGP-key repositories. This key was set up during the early days of ARIN, and the passphrase for the key is, as of this writing, MIA. This prevents ARIN from using the key to sign anything, and furthermore prevents ARIN from removing the key from the key repositories mentioned above. Although ARIN could proceed by generating a new PGP-key, we would need to use a limited distribution mechanism that excludes well-known servers, since more than one key for the same e-mail address cannot exist in the key servers. Such distribution might occur at key-signing parties at ARIN meetings, et.al. so that persons wanting to rely upon PGP-signed communications from ARIN can validate using the proper key. However, those individuals inadvertently using the well-known repositories for ARIN's "old" PGP-key to encrypt their communication with ARIN will likely get an "invalid signature" type of response f rom ARIN since they have used a key that we cannot decrypt (because the passphrase is MIA). It is noted that all of these issues regarding the lost passphrase can be overcome (and, is overcome in generally accepted practice) by changing the e-mail address in question that's bound to the PGP-key. The difficulties introduced by changing the well-known e-mail address of hostmaster at arin.net to some other address makes such a change an unattractive option. 6. Currently ARIN uses two e-mail addresses, hostmaster at arin.net and reassign at arin.net, to accept e-mail. The purpose for the differentiation is primarily workflow-related: submissions to hostmaster are generally handled manually while submissions to reassign are generally able to be handled by automated software. PGP-key best practice dictates that each e-mail address have a separate key, and we would implement according to this practice. Staff notes that having two keys, and two addresses, may create opportunities for confusion or inadvertent misapplication of the wrong key to e-mails during functions like verification or encryption (i.e. use hostmaster's key to encrypt a submission to reassign). The concern is partially ameliorated by the fact that many MUAs will automatically select the proper key for encryption or verification based upon the e-mail address, but staff is aware that significant amounts of e-mail communication takes place outside of typical MUAs (e.g., c ustom scripts, etc.), leaving some degree of concern. 7. The proposal text "ARIN shall PGP-sign all outgoing hostmaster email with the hostmaster role key, and staff members may optionally also sign mail with their own individual keys" implies that staff may sign with arbitrarily-sourced individual keys. We intend that if such keys are generated, they would be signed with ARIN's hostmaster key and controlled procedurally to maintain communication integrity between ARIN and its customers, including publication of those keys in widely-known repositories. B. ARIN General Counsel Counsel has some concerns regarding liability that might be imposed on ARIN to by proposed policy 2007-1. These concerns may be resolved by explanation to cure my ignorance, or by editing if the concern exists. My most specific concern is that ARIN 'validate a chain of trust not longer than 5 steps"....I am concerned about fraud that may occur somewhere in the 5 steps that is not detected by ARIN. I have been told by techies that such an undetected fraud could easily occur. Does this policy leave ARIN responsible for damages to third parties, including our members, if it does not detect such fraud? It seems to me that establishment of an overall ARIN policy of cooperating in using PGP does not create this concern, but this specific language does. Is the additional language integral to PGP and hence unusual and unobjectionable? I apologize in advance if this is an instance where my lack of technical knowledge creates confusion. IV. Resource Impact - Significant The resource impact of implementing this policy is significant. Barring any unforeseen resource requirements, this policy could be implemented within 4-12 months from the date of the ratification of the policy by the ARIN Board of Trustees. Implementation would not require the acquisition of staff personnel or equipment. It will require the following: - Template change - Revision to Registration Software - Revision to Directory Services - Revisions to registration guidelines - Staff training Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-1 Reinstatement of PGP Authentication Method Proposal type: New Policy term: Permanent Policy statement: ADDITION TO NRPM 12 Authentication Methods 12.1 Mail-From This section intentionally left blank. 12.2 PGP ARIN accepts PGP-signed email as authentic communication from authorized Points of Contact. POCs may denote their records "crypt-auth," subsequent to which unsigned communications shall not be deemed authentic with regard to those records. 12.3 X.509 This section intentionally left blank. UPDATES TO TEMPLATES ARIN shall update templates as necessary to identify and distinguish between mail-from, PGP, and X.509 authentication methods. UPDATES TO DOCUMENTATION ARIN shall update documentation as appropriate to explain the differences between mail-from, PGP, and X.509 authentication methods. KEY USE IN COMMUNICATION: ARIN shall accept PGP-signed communications, validate that a chain of trust not longer than five steps exists between the signing key and the ARIN hostmaster role key, compare the signing key to the identity of the authorized POCs for records referenced in the correspondence, and act appropriately based upon the validity or invalidity of the signature. ARIN shall PGP-sign all outgoing hostmaster email with the hostmaster role key, and staff members may optionally also sign mail with their own individual keys. ARIN shall accept PGP-encrypted communications which are encrypted using ARIN's hostmaster public key. ARIN shall not encrypt any outgoing communications except at the prior request of the recipient. Policy Rationale Rationale: Globally, PGP is the most commonly used cryptographic authentication method between RIRs and resource recipients who wish to protect their resource registration records against unauthorized modification. The PGP-auth authentication method is supported by RIPE, APNIC, and AfriNIC, LACNIC supports an equivalent mechanism, and PGP was historically supported by the InterNIC prior to ARIN's formation. By contrast, current ARIN resource recipients have only two options: "mail-from," which is trivially spoofed and should not be relied upon to protect important database objects, and X.509, which involves a rigorous and lengthy proof-of-identity process and compels use of a compatible MUA, a combination which has dissuaded essentially all of ARIN's constituents. Additionally, X.509's centralized failure mode is technically and ideologically repugnant to some members of the community, who should not be forced to choose between two evils. There isn't a lot of work to do here, and certainly nothing tricky. PGP is simple code, which was supported by the InterNIC, and which the other RIRs deployed without a second thought or complaint. If RIPE and APNIC have always done this, the InterNIC did it before ARIN was formed, and LACNIC and AfriNIC took the need for cryptographic security for granted as a part of their startup process, we see no reason why ARIN should be the only RIR to not offer this most basic of protections to its members. We need to get PGP support reinstated, so that our records can be protected against hijacking and vandalism, and so we won't look like idiots as the only one of the five regions that can't figure this stuff out. Timetable for implementation: Immediate From info at arin.net Fri Apr 13 14:22:31 2007 From: info at arin.net (Member Services) Date: Fri, 13 Apr 2007 14:22:31 -0400 Subject: Policy Proposal 2007-12 - Staff Assessment Message-ID: <461FCA67.60702@arin.net> Policy Proposal 2007-12 IPv4 Countdown Policy Proposal ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal 2007-12 is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_12.html II. Understanding of the proposal ARIN staff understands that this proposal would halt direct IPv4 allocations and assignments from ARIN on the day which is exactly two years after the day that the IANA pool is equal to 30 /8 IPv4 address blocks. III. Issues and concerns A. ARIN Staff 1. It is unclear what the reference to ?There will be no change to the policy on A-date? is. What does this mean? On this day and in the future? 2. What happens to customers who come in after T-date to request IPv4 space? Do we deny these requests? Do we recommend IPv6? Do we do nothing? How can we deny a legitimate request when v4 resources still exist? 3. Author did not indicate placement. Could be put in as new section 4.9 of the NRPM Section 4.9. Also, that section would need a heading, perhaps, "Availability of IPv4 Address Space". 4. Need to make clear this applies to both assignments and allocations. 5. Change text that says "RIRs must" to "ARIN must". And references such as, "set the date" to "ARIN will set the date?" 6. Change /8 references to have amounts written out, such as "10*/8" to "ten /8s". 7. The following text lacks criteria and detail, "- It is however possible to move T-date forward at the point where address consumption exceeds the projections during the course of two years". Who decides, what projections, how much? 8. Remove "Allocations or assignments to "critical infrastructure" after T-date should be defined by a separate policy." 9. Prior to T date, there may be an increase in requests, perhaps necessitating more staff. 10. What happens to reserved space? 11. If IPv4 is replaced by IPv6 then one could assume that organizations would return their IPv4 back to ARIN and that space would be available for reallocation. However, this policy would effectively preclude ARIN from reusing this returned space. 12. The proposal would hasten the loss of revenue by approximately 12% per year (4% if the IPv6 fee waiver was lifted). B. ARIN General Counsel This proposal addresses an important policy issue that is worthy of extended debate and consideration, but it proposes to do so in a way that may inadvertently create profound legal issues that would dramatically increase ARIN's potential legal liabilities. The policy proposes to set a hard date to terminate IPv4 allocations. Adoption and implementation of such a policy has a clear legal impact: it could, for example, be deemed a denial of service by ARIN, which is a utility provider of such services. For example, if IPV4 is exhausted and unavailable from IANA, there is little or no legal risk to ARIN. However, there are dramatically increased risks to ARIN associated with refusing to provide IPv4 addresses if ARIN has such addresses available, and is refusing to issue any of them to anyone based on a well intentioned but absolute policy. ARIN's legal counsel will need to carefully evaluate any policy which results from this activity. Based on my current understanding, and I am willing to constantly reconsider and do additional research, I am likely to recommend that ARIN not adopt such a policy in its current form because of the profound legal risks it creates. This is one of the few times my advice prior to consideration of a policy has been so direct. IV. Resource Impact - Minimum The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. Determining A and T dates assumes coordination among the RIRs. Implementation would not require the acquisition of staff personnel or equipment. It will require the following: - Revisions to registration guidelines - Staff Training Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-12 IPv4 Countdown Policy Proposal Proposal type: new Policy term: renewable Policy statement: - Set the date for termination of (IPv4) allocations and the date of announcement Set the date to terminate allocations as a general rule, and announce it a certain period in advance. Define the date of announcement as "A-date" and the date to terminate allocations as "T-date". The two dates will be set as follows: A-date (Date of Announcement): - The day in which the IANA pool becomes less than 30*/8 - RIRs must announce "T-date" on this day, which is defined later (*) There will be no changes in the policy on A-date T-date(Date of Termination): - Exactly two years after A-date - 10*/8 blocks should remain at T-date, and defined as two years after A-date, based on the current pace of allocations - It is however possible to move T-date forward at the point where address consumpution exceeds the projections during the course of two years (*) new allocations/assignments from RIRs should terminate on T-date as a general rule. Allocations or assignments to "critical infrastructure" after T-date should be defined by a separate policy. Rationale: 1. Introduction The exhaustion of IPv4 address is approaching round the corner. Geoff Huston's latest projection at Potaroo (as of January 6, 2007) (http://www.potaroo.net/tools/ipv4/) draws the date of IANA pool exhaustion as 31st May 2011, and that of RIR pool as 14th July 2012. Tony Hain projects similar dates based on a different algorithm of his own. From these data, we may observe that if that the current allocation trend continues, the exhaustion of IPv4 address space is expected to take place as early as within the next five years. ICANN/IANA and RIRs must co-ordinate with stakeholders to achieve smooth termination of IPv4 address space as the Internet bodies responsible for stable management and distribution of IP number resources. This proposal provides some ideas as well as concrete examples of the policy that helps IPv4 allocations come to an end with "the minimum confusion" and in "as fair manner as possible". "Five years at the earliest" is not too far in the future for the exhaustion of IPv4 address space. Assuming the minimum of one year is required for sufficient policy discussions with this proposal as a start, and two years for preparation and transfer by LIRs, we need to start the discussions right at this time. 2. Summary of current problems Despite the fact that several projections are made on IPv4 address to run out as early as within the next few years, no discussions are taking place on any of the RIR's policy fora. (we have submitted the same proposal to APNIC on January 2007) This section lists possible problems if no policies are defined to prepare for the terminal period of allocations. 2-1. LIR LIRs currently do not consider IPv4 address exhaustion as an imminent issue in the first place. It is possible that they will finally realize the situation only when impacts of the exhaustion becomes visible as a practical matter, and lead to confusions such as re-addressing their network or making subsequent requests at the last minute in within a limited time frame. There could also be cases where allocations blocks cannot be allocated to some of the LIRs even though requests are submitted on the same day. Moreover, although it would be necessary for LIRs to announce to their customers that IPv4 address space will not be available for assignments eventually, it is difficult to plan this timing without clear policy for the last phase of allocations. As new IPv4 address allocations space will no longer be available, LIRs have no choice but to build networks based on IPv6. However, there are risks of trouble if preparations are made from that point in time, as it will lead to premature actions even if some time can be bought by re-addressing and subsequent allocations. Lastly, using up all available IPv4 address space will disable assignments to services inevitable for co-existence of IPv4 and IPv6 networks, such as the translator service between the two networks, which it may create situation where transfer to IPv6 network will not even be possible. 2-2. RIR/NIR It is likely that smooth allocations by RIRs/NIRs will be hindered by rush of inquiries during the terminal phase of allocations. 2-3. End users End users generally receive address assignments from ISPs accompanied with Internet connection service. If an ISP no longer has IPv4 address space available, nor unable to provide IPv6 service, end users will not be able to receive services from that ISP. Moreover, if the terminal date of allocations remains ambiguous, it may leave end users behind to prepare for IPv6 ready network. 3. Benefits There will be the following benefits by implementing the policy for IPv4 address exhaustion as proposed on this paper. 3-1. LIR LIRs will be able to consciously plan their addressing within their networks if the final date of allocations is clearly demonstrated. Keeping a certain amount of unallocated address blocks enables allocations/assignments for "critical infrastructure" after the termination of regular allocations, which will be explained later section in more details. 3-2. RIR/NIR Announcing the date of terminating allocations in advance and ensuring that all allocations before this date will be made according to the policy at the time enables RIRs/NIRs to make the last allocation without confusions and avoids causing feelings of unfairness among LIRs and end users. In addition, consistent policy applied to all RIRs removes bias towards certain region as well as inter-regional unfairness. The period which IPv6 support is completed becomes clear, therefore, RIRs/NIRs can prepare for this. 3-3. End user As this proposal enables LIRs to prepare for the terminal period of allocations in advance, it reduces the risk of delays/ suspensions of assignments from LIRs to enduers, and end users will be able to continuously receive services from LIRs. As in the case of LIRs, end users will be able to prepare for IPv6 support by the date of allocation termination is clarified. In addition, IPv6 connectivity as well as IPv4 address required during the allocation termination period will be smoothly secured by LIRs preparing for such period. As listed above, there will be important, notable benefits for stakeholders as a result of this policy. It is therefore necessary to take the following actions to achieve a smooth transfer to IPv6 and prevent causing instability in the Internet as well as; - start discussions on allocation scheme during the exhaustion period, - indicate a roadmap to exhaustion after raising awareness on the issue, and - allow enough time for LIRs to plan timing of addressing of their networks, submit allocation requests, and consider how to switch to IPv6. 4. Proposal principles As the first step to discuss IPv4 exhaustion planning, we would like to have an agreement(consensus) on the following four principles. -------------------------------------------------------------------- (1) Global synchronization: All five RIRs will proceed at the same time for measures on IPv4 address exhaustion. (2) Some Blocks to be left: Keep a few /8 stocks instead of distributing all. (3) Keeping current practices until the last moment : Maintain the current policy until the last allocation. (4) Separate discussions on "Recycle" issue : Recovery of unused address space should be discussed separately. -------------------------------------------------------------------- (1) Global synchronization: All RIRs must proceed at the same time to take measures for IPv4 address exhaustion. This is important not only for ensuring fairness for LIRs across the regions, but alsot to prevent confusions such as attempts to receive allocations from an RIR outside their region. The five RIRs should facilitate bottom-up discussions, which should be well coordinated under the leaderships of ICANN ASO and NRO. (2) Some blocks to be left: It is not practical to consider that IPv4 address blocks can be allocated to the last piece. It is expected to cause confusions if one party can receive an allocation while the other has to give up, just with a touch of a difference. The best solution to avoid such confusion is to set in advance, a date in which one is able to receive an allocation if requests are submitted before this timeline. Furthermore, there are few cases where allocations or assignments of IPv4 address space become absolutely necessary in the future. For example, requirements to start a translator service between IPv4 and IPv6 networks should be supported, and there may be some requirements in the future that are beyond our imagination at this current moment. As such, a date to stop allocations under the current policy should be set/defined so that certain number of IPv4 address blocks will be kept as stocks instead of allocating all blocks without remains. (3) Maintaining current practices until the last moment : Allocations should be made based on the current policy until the time to terminate allocations. As the IPv4 Internet has now developed into a social infrastructure supporting large number of businesses, making large changes in the current policy towards conservation within the next one or two years will lead to large-scale confusions, and difficult in the reality. (4) Separate discussion from "Recycle" issue Recovering unused allocated/assigned address blocks is an important measure, and in fact, it has already be discussed and implemented in each RIR regions. This issue, however should be considered separately from this proposal as recovery of a few /8 blocks extends the lifetime of IPv4 for less than one year while efforts for the recovery is expected to require substantial time. 5. Rationale for "A-date" & "T-date" A-date is set in order to: - Allow some grace period and period for networks to be IPv6 ready until the termination of allocations. - Prevent unfairness among LIRs by clarifying the date, such as not being able to receive allocations by a small difference in timing. The rationale for setting A-date as "when IANA pool becomes less than 30*/8" is as follows: The rate of allocations from IANA to RIRs after 2000 is as follows. 2000 : 4*/8 2001 : 6*/8 2002 : 4*/8 2003 : 5*/8 2004 : 9*/8 2005 : 13*/8 2006 : 10*/8 Approximately 10*/8 has been allocated annually after 2003, and the consumption is likely to accelerate with rise of the last minute demands. As it is better to keep minimum stocks of address pool at IANA, 30*/8 is set as the threshold value, and allocations should be terminated two years after it reaches the value, which ensures that IANA/RIRs secure the address space for allocations/assignments to critical infrastructure. 6. Effect on RIR members RIR members are expected to concretely grasp the termination date of allocations and take actions within their organization to prepare for the event. Timetable for implementation: Immediate after all 5 RIRs ratified this policy. From info at arin.net Mon Apr 16 08:51:33 2007 From: info at arin.net (Member Services) Date: Mon, 16 Apr 2007 08:51:33 -0400 Subject: Policy Proposal 2006-7 - Staff Assessment Message-ID: <46237155.8030404@arin.net> Policy Proposal 2006-7 Changes to IPv6 initial allocation criteria ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal 2006-7 is available as Annex A below and at: http://www.arin.net/policy/proposals/2006_7.html II. Understanding of the proposal ARIN staff understands this proposal would add to the list of criteria for an initial allocation of IPv6 address space (NRPM section 6.5.1.1.). Specifically, in addition to the common criteria, if an ISP is not known, nor can it provide a plan, it can instead attempt to justify intent to announce the address space within one year. III. Issues and concerns A. ARIN staff 1. ARIN staff is concerned about confusion that may occur if the text is inserted as the author indicated (letter "d" already has an "or"). ARIN staff has suggested alternative placement; see Annex B below. 2. How can staff verify that an organization is new to providing "Internet services"? 3. What happens at the end of 1 year if the v6 block is not announced? 4. What if the IPv6 address space is used on a ?private network? and can?t be seen from the public Internet? B. ARIN General Counsel This policy as proposed poses no significant legal risks for ARIN. IV. Resource Impact - Minimum The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. Implementation would not require the acquisition of staff personnel or equipment. It will require the following: - Revisions to registration guidelines - Staff Training Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2006-7 Changes to IPv6 initial allocation criteria Proposal type: Insert a new additional line item e. to 6.5.1.1 of NRPM Policy term: permanent Policy statement: New organizations need a policy that allows them to apply for IPv6 address space. To provide this we need to insert a new additional line item to 6.5.1.1. The new line item would be line 'e' as follows: e. OR be an organization new to providing internet services, and can justify intent to announce the requested IPv6 address space within one year, through records such as contracts, inventory and/or other applicable documentation. Rationale: - New organizations who do not want to use IPv4 at all and start off using IPv6 addresses only, need a policy that gives them permission to do so. This is also valid for existing companies that may or may not have assigned IPv4 addresses and now want to start offering IPv6 services. These organizations may also wish to request IPv4 at the same time. - One year is given as the sufficient time frame to actually implement usage of the IPv6 address space and reveal if the 'said organization' is truly using the IPv6 space granted. -Every means of documentation that can reveal 'true intent of use' is not listed as this can be a very long list and should be left to the discretion of the RIR staff. -An ISP or LIR may decide to assign a different prefix size than /48. For example, a cellular operator may use /64. -ASN is not required because as long as they are statically routed to an upstream and don't want to run bgp/announce directly to the Internet, they don't need an ASN, therefore we shouldn't create policy that would contribute to ASN bloat. - Organization in this is defined as a Corporation, ISP, LLC et al. In SUMMARY if this policy is implemented the change to the NRPM would read as follows: 6.5.1.1 Initial allocation criteria To qualify for an initial allocation of IPV6 address space, an organization must: a be a LIR; b. not be an end site; c. plan to provide IPV6 connectivity to which it will assign IPV6 address space, by advertising that connectivity through its single aggregated address allocation; d. be an existing, known ISP in the ARIN region or have a plan for making at least 200/48 assignments to other organizations within five years. e. OR be an organization new to providing internet services, and can justify intent to announce the requested IPV6 address space within one year, through records such as contracts, inventory and/or other applicable documentation. Timetable for implementation: Immediate ##*## Annex B ARIN staff suggested format for the insertion of the policy text 6.5.1.1. Initial allocation criteria To qualify for an initial allocation of IPv6 address space, an organization must: a. be an LIR; b. not be an end site; c. plan to provide IPv6 connectivity to organizations to which it will assign IPv6 address space, by advertising that connectivity through its single aggregated address allocation; and d. meet at least one of the following: 1. be an existing, known ISP in the ARIN region. 2. have a plan for making at least 200 /48 assignments to other organizations within five years. 3. be an organization new to providing internet services that can justify intent to announce the requested IPv6 address space within one year, through records such as contracts, inventory and/or other applicable documentation. From info at arin.net Mon Apr 23 09:04:48 2007 From: info at arin.net (Member Services) Date: Mon, 23 Apr 2007 09:04:48 -0400 Subject: ARIN XIX Underway Message-ID: <462CAEF0.1040804@arin.net> The ARIN XIX Public Policy and Members Meeting is now underway in San Juan, Puerto Rico. For those in the community unable to make it to San Juan for the meeting, ARIN is once again offering a webcast of the Public Policy and Members Meetings via RealNetworks Helix Server. The times of the broadcast are as follows (All times are Atlantic Standard Time(AST), (UTC/GMT -4 hours): Public Policy Meeting (Policy and technical discussions) Monday, 23 April 9AM - 5PM Tuesday, 24 April 9AM - 5PM Members Meeting Wednesday, 25 April 9 AM - 12PM For those who already registered to participate remotely, you may send in questions or comments during the times listed above. The full agenda is available at http://www.arin.net/ARIN-XIX/agenda.html. For a link to the live webcast feed, for details about how to connect to the webcast, or to refer to the Remote Participation Acceptable Use Policy, please see: http://www.arin.net/ARIN-XIX/webcast.html Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Wed Apr 25 10:20:17 2007 From: info at arin.net (Member Services) Date: Wed, 25 Apr 2007 10:20:17 -0400 Subject: Policy Proposal: Removal of ISP Immediate Need from End-User Message-ID: <462F63A1.6050101@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The AC will review this proposal and may decide to: 1. Accept the proposal as a formal policy proposal as it is presented; 2. Work with the author to: a) clarify the language or intent of the proposal; b) divide the proposal into two (2) or more proposals; or c) combine the proposal with other proposals; or, 3. Not accept the proposal as a formal policy proposal. The AC will review this proposal at their next regularly scheduled meeting. If the AC accepts the proposal, then it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. If the AC does not accept the proposal, then the AC will explain that decision; and at that time the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The 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: Removal of ISP Immediate Need from End-User Author: Rob Seastrom, David Williamson, Owen DeLong Proposal Version: 0.1 Submission Date: 4/24/07 Proposal type: delete Policy term: permanent Policy statement: Delete section 4.3.4, which reads: 4.3.4. Additional considerations End-users may qualify for address space under other policies such as Immediate need [4.2.1.6] or Micro-allocation [4.4]. from the NRPM. Rationale: As discussed at ARIN XIX, section 4.3.4 creates a conflict with section 4.2.1.6 in that section 4.2.1.6 specifically excludes end users while section 4.3.4 is specifically for end users. Prior to the development of the multihoming policy for end users, the immediate need policy was required in order to support end users being able to get address space under some circumstances. The "immediate need" title is a misnomer as it is more an issue of "initial need without prior address utilization" than "immediate need". Such initial needs for end users are now addressed best through the multihoming policy. Timetable for implementation: immediate From info at arin.net Wed Apr 25 10:20:37 2007 From: info at arin.net (Member Services) Date: Wed, 25 Apr 2007 10:20:37 -0400 Subject: Policy Proposal: Resource Renewal and Verification Message-ID: <462F63B5.3000809@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The AC will review this proposal and may decide to: 1. Accept the proposal as a formal policy proposal as it is presented; 2. Work with the author to: a) clarify the language or intent of the proposal; b) divide the proposal into two (2) or more proposals; or c) combine the proposal with other proposals; or, 3. Not accept the proposal as a formal policy proposal. The AC will review this proposal at their next regularly scheduled meeting. If the AC accepts the proposal, then it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. If the AC does not accept the proposal, then the AC will explain that decision; and at that time the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The 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: Resource Renewal and Verification Author: Owen DeLong Proposal Version: 0.0.1 Submission Date: 4/24/07 Proposal type: new Policy term: permanent Policy statement: At any time after a resource is allocated or assigned, ARIN staff may audit the usage of the resource to verify that it is in compliance with the policies under which it was issued and the RSA which governs its use. Should the staff develop reason to believe that such usage no longer meets ARIN policy, ARIN shall immediately notify the appropriate POCs and attempt to resolve the issue. Should the issue not be resolved to ARIN's satisfaction, ARIN shall have the option of not renewing the effected resources at the next renewal of the organization. If renewal is not at least 90 days out when the POC is notified of ARIN's decision not to renew, a 90 day grace period shall be granted. Any decision not to renew may be appealed to the BoT who shall act an the appeal within 30 days. The decision of the BoT shall be final. Rationale: It was my understanding that ARIN staff already had this option. However, it is not clear in policy that such an option exists. Codifying this ability will prevent fraud and reduce the likelihood of resources being obtained under false pretense. For example, a claim was made at a policy meeting that organizations can/do apply under the multi-home policy, then become single-homed and remain single-homed, essentially doing an end-run on the multi-home policy. Timetable for implementation: Immediate From info at arin.net Wed Apr 25 16:00:47 2007 From: info at arin.net (Member Services) Date: Wed, 25 Apr 2007 16:00:47 -0400 Subject: Policy Proposal 2007-1 - Last Call Message-ID: <462FB36F.50308@arin.net> Policy Proposal 2007-1 Reinstatement of PGP Authentication Method The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that there is community consensus in favor of the proposal and moved it to last call. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 24 April 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XIX/mem.html The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_1.html Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 23:59, Eastern Time, 9 May 2007. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ##*## Policy Proposal 2007-1 Reinstatement of PGP Authentication Method Proposal type: New Policy term: Permanent Policy statement: ADDITION TO NRPM 12 Authentication Methods 12.1 Mail-From This section intentionally left blank. 12.2 PGP ARIN accepts PGP-signed email as authentic communication from authorized Points of Contact. POCs may denote their records "crypt-auth," subsequent to which unsigned communications shall not be deemed authentic with regard to those records. 12.3 X.509 This section intentionally left blank. UPDATES TO TEMPLATES ARIN shall update templates as necessary to identify and distinguish between mail-from, PGP, and X.509 authentication methods. UPDATES TO DOCUMENTATION ARIN shall update documentation as appropriate to explain the differences between mail-from, PGP, and X.509 authentication methods. KEY USE IN COMMUNICATION: ARIN shall accept PGP-signed communications, validate that a chain of trust not longer than five steps exists between the signing key and the ARIN hostmaster role key, compare the signing key to the identity of the authorized POCs for records referenced in the correspondence, and act appropriately based upon the validity or invalidity of the signature. ARIN shall PGP-sign all outgoing hostmaster email with the hostmaster role key, and staff members may optionally also sign mail with their own individual keys. ARIN shall accept PGP-encrypted communications which are encrypted using ARIN's hostmaster public key. ARIN shall not encrypt any outgoing communications except at the prior request of the recipient. Policy Rationale Rationale: Globally, PGP is the most commonly used cryptographic authentication method between RIRs and resource recipients who wish to protect their resource registration records against unauthorized modification. The PGP-auth authentication method is supported by RIPE, APNIC, and AfriNIC, LACNIC supports an equivalent mechanism, and PGP was historically supported by the InterNIC prior to ARIN's formation. By contrast, current ARIN resource recipients have only two options: "mail-from," which is trivially spoofed and should not be relied upon to protect important database objects, and X.509, which involves a rigorous and lengthy proof-of-identity process and compels use of a compatible MUA, a combination which has dissuaded essentially all of ARIN's constituents. Additionally, X.509's centralized failure mode is technically and ideologically repugnant to some members of the community, who should not be forced to choose between two evils. There isn't a lot of work to do here, and certainly nothing tricky. PGP is simple code, which was supported by the InterNIC, and which the other RIRs deployed without a second thought or complaint. If RIPE and APNIC have always done this, the InterNIC did it before ARIN was formed, and LACNIC and AfriNIC took the need for cryptographic security for granted as a part of their startup process, we see no reason why ARIN should be the only RIR to not offer this most basic of protections to its members. We need to get PGP support reinstated, so that our records can be protected against hijacking and vandalism, and so we won't look like idiots as the only one of the five regions that can't figure this stuff out. Timetable for implementation: Immediate From info at arin.net Wed Apr 25 16:01:04 2007 From: info at arin.net (Member Services) Date: Wed, 25 Apr 2007 16:01:04 -0400 Subject: Policy Proposal 2007-3 - Last Call Message-ID: <462FB380.4040606@arin.net> Policy Proposal 2007-3 Documentation of the X.509 Authentication Method The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that there is community consensus in favor of the proposal and moved it to last call. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 24 April 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XIX/mem.html The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_3.html Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 23:59, Eastern Time, 9 May 2007. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ##*## Policy Proposal 2007-3 Documentation of the X.509 Authentication Method Policy statement Proposal type: New Policy term: Permanent Policy statement: DELETION FROM THE NRPM 12.3 X.509 This section intentionally left blank. ADDITION TO THE NRPM 12.3 X.509 ARIN accepts X.509-signed transactions as authentic communication from authorized Points of Contact. POCs may denote their records "crypt-auth," subsequent to which unsigned communications shall not be deemed authentic with regard to those records. Rationale: This policy complements the previously-proposed "Reinstatement of PGP Authentication Method" which introduces section 12 to the NRPM. Section 12 relates the existence of three authentication methods. Two of those, mail-from and X.509, were preexisting but not documented within the NRPM. This policy proposal simply seeks to provide brief documentation of the existence of the X.509 authentication method. Because the specific wording of the documentation may be subject to debate, and is in no way interdependent upon the documentation of the other two methods, it is being proposed in a separate policy, so that consensus may be more easily reached. Timetable for implementation: Immediate From info at arin.net Wed Apr 25 16:01:18 2007 From: info at arin.net (Member Services) Date: Wed, 25 Apr 2007 16:01:18 -0400 Subject: Policy Proposal 2006-7 - To Be Revised Message-ID: <462FB38E.6000003@arin.net> Policy Proposal 2006-7 Changes to IPv6 initial allocation criteria The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that while there is not community consensus in favor of the proposal there is consensus that the proposal should be revised and discussed further. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 24 April 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XIX/mem.html The AC will work with the author of the proposal to make the community suggested revisions and return the proposal to the PPML for further discussion. The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2006_7.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ##*## Policy Proposal 2006-7 Changes to IPv6 initial allocation criteria Proposal type: Insert a new additional line item e. to 6.5.1.1 of NRPM Policy term: permanent Policy statement: New organizations need a policy that allows them to apply for IPv6 address space. To provide this we need to insert a new additional line item to 6.5.1.1. The new line item would be line 'e' as follows: e. OR be an organization new to providing internet services, and can justify intent to announce the requested IPv6 address space within one year, through records such as contracts, inventory and/or other applicable documentation. Rationale: - New organizations who do not want to use IPv4 at all and start off using IPv6 addresses only, need a policy that gives them permission to do so. This is also valid for existing companies that may or may not have assigned IPv4 addresses and now want to start offering IPv6 services. These organizations may also wish to request IPv4 at the same time. - One year is given as the sufficient time frame to actually implement usage of the IPv6 address space and reveal if the 'said organization' is truly using the IPv6 space granted. -Every means of documentation that can reveal 'true intent of use' is not listed as this can be a very long list and should be left to the discretion of the RIR staff. -An ISP or LIR may decide to assign a different prefix size than /48. For example, a cellular operator may use /64. -ASN is not required because as long as they are statically routed to an upstream and don't want to run bgp/announce directly to the Internet, they don't need an ASN, therefore we shouldn't create policy that would contribute to ASN bloat. - Organization in this is defined as a Corporation, ISP, LLC et al. In SUMMARY if this policy is implemented the change to the NRPM would read as follows: 6.5.1.1 Initial allocation criteria To qualify for an initial allocation of IPV6 address space, an organization must: a be a LIR; b. not be an end site; c. plan to provide IPV6 connectivity to which it will assign IPV6 address space, by advertising that connectivity through its single aggregated address allocation; d. be an existing, known ISP in the ARIN region or have a plan for making at least 200/48 assignments to other organizations within five years. e. OR be an organization new to providing internet services, and can justify intent to announce the requested IPV6 address space within one year, through records such as contracts, inventory and/or other applicable documentation. Timetable for implementation: Immediate From info at arin.net Wed Apr 25 16:01:29 2007 From: info at arin.net (Member Services) Date: Wed, 25 Apr 2007 16:01:29 -0400 Subject: Policy Proposal 2007-4 - Last Call Message-ID: <462FB399.5030105@arin.net> Policy Proposal 2007-4 Changes to IPv6 policy - removal of "interim" consideration The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that there is community consensus in favor of the proposal and moved it to last call. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 24 April 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XIX/mem.html The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_4.html Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 23:59, Eastern Time, 9 May 2007. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ##*## Policy Proposal 2007-4 Changes to IPv6 policy - removal of "interim" consideration Proposal type: delete Policy term: permanent Policy statement: Delete following text at section 6.1.1 of NRPM: "This policy is considered to be an interim policy. It will be reviewed in the future, subject to greater experience in the administration of IPv6." Rationale: The actual text suggest that it is an interim policy, however it is not longer the case. It is clear that any policy is always subjected to changes, however other policies don't have such text. It may be even considered as a negative "message" for IPv6 deployment, especially because the possible "reading" as "not enough experience and this is going to be changed, better wait", which is not a real situation. No financial/liability implications for the community and ARIN are foreseen. No special conditions, fees, exceptions, etc. seem to be required. Timetable for implementation: Immediate From info at arin.net Wed Apr 25 16:01:39 2007 From: info at arin.net (Member Services) Date: Wed, 25 Apr 2007 16:01:39 -0400 Subject: Policy Proposal 2007-2 - Last Call Message-ID: <462FB3A3.9020902@arin.net> Policy Proposal 2007-2 Documentation of the Mail-From Authentication Method The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that there is community consensus in favor of the proposal and moved it to last call. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 24 April 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XIX/mem.html The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_2.html Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 23:59, Eastern Time, 9 May 2007. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ##*## Policy Proposal 2007-2 Documentation of the Mail-From Authentication Method Proposal type: New Policy term: Permanent Policy statement: DELETION FROM THE NRPM 12.1 Mail-From This section intentionally left blank. ADDITION TO THE NRPM 12.1 Mail-From Mail-From is the default authentication method by which registration records are protected from vandalism. If a registrant fails to designate a more secure method, any subsequent email which bears the sender address of an authorized Point of Contact may be deemed authentic with regard to the registrant's records. Since it is trivial to forge a sender address, Mail-From should not be regarded as secure. Use of Mail-From authentication is not recommended to any registrant who has the means to implement either of the more secure cryptographic authentication methods. Rationale: This policy complements the previously-proposed "Reinstatement of PGP Authentication Method" which introduces section 12 to the NRPM. Section 12 relates the existence of three authentication methods. Two of those, mail-from and X.509, were preexisting but not documented within the NRPM. This policy proposal simply seeks to provide brief documentation of the existence of the mail-from authentication method. Because the specific wording of the documentation may be subject to debate, and is in no way interdependent upon the documentation of the other two methods, it is being proposed in a separate policy, so that consensus may be more easily reached. Timetable for implementation: Immediate From info at arin.net Wed Apr 25 16:01:48 2007 From: info at arin.net (Member Services) Date: Wed, 25 Apr 2007 16:01:48 -0400 Subject: Policy Proposal 2007-5 - Abandoned Message-ID: <462FB3AC.5090306@arin.net> Policy Proposal 2007-5 Changes to IPv6 policy - removal of "multiple /48" justification The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that there is not community consensus in favor of the proposal and abandoned it. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 24 April 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XIX/mem.html In order for this proposal to be further considered the author must use the last call petition process as defined in the ARIN Internet Resource Policy Evaluation Process. This policy will be considered to be abandoned if the author of the proposal does not initiate a last call petition by 23:59, Eastern Time, 2 May 2007. The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_5.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ##*## Policy Proposal 2007-5 Changes to IPv6 policy - removal of "multiple /48" justification Proposal type: delete Policy term: permanent Policy statement: Delete section 6.5.4.2 of NRPM. Rationale: The current text requires the LIR to justify to the RIR/NIR when assigning multiple /48s to a single end site. It seems that the reason for this requirement is the lack of experience, which seems unreasonable after a few years this policy has been implemented, even if may not have been specific cases which used this policy section. It seems useless, now that there is already deployment experience, to require a justification from the LIR to ARIN for assigning multiple /48s (or a shorter prefix, such as for example a /47). It is up to the LIR to require the justification to its own customers and decide according to it. The LIR will be already responsible to justify to ARIN the usage of any allocated block(s) when requesting for more, and this will already implicate an implicit justification of this kind of assignments. With this policy change, both ARIN and LIR staff will save resources in a justification, which seems unnecessary and should be completely on the hands of the LIR itself. No financial/liability implications for the community and ARIN are foreseen. No special conditions, fees, exceptions, etc. seem to be required. Timetable for implementation: Immediate From info at arin.net Wed Apr 25 16:01:56 2007 From: info at arin.net (Member Services) Date: Wed, 25 Apr 2007 16:01:56 -0400 Subject: Policy Proposal 2007-6 - Abandoned Message-ID: <462FB3B4.3030609@arin.net> Policy Proposal 2007-6 IPv4 PI minimum size change The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that there is not community consensus in favor of the proposal and abandoned it. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 24 April 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XIX/mem.html In order for this proposal to be further considered the author must use the last call petition process as defined in the ARIN Internet Resource Policy Evaluation Process. This policy will be considered to be abandoned if the author of the proposal does not initiate a last call petition by 23:59, Eastern Time, 2 May 2007. The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_6.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ##*## Policy Proposal 2007-6 IPv4 PI minimum size change Proposal type: modify Policy term: permanent Policy statement: In section 4.3.2.2 of the NRPM, change all occurences of "/22" to "/24". (That is, replace the existing 4.3.2.2 with this text: For end-users who demonstrate an intent to announce the requested space in a multihomed fashion, the minimum block of IP address space assigned is a /24. If assignments smaller than a /24 are needed, multihomed end-users should contact their upstream providers. When prefixes are assigned which are longer than /20, they will be from a block reserved for that purpose.) Remove references to IPv4 in section 4.4, as they are no longer relevant. Section 4.4 could be moved, at the discretion of the NRPM editors, to somewhere in section 6, for clarity. Rationale: The rationale for moving the allocation "edge" for IPv4 PI space to /24 has three fundamental points: routing slot consumption would be unchanged, it reflects widespread routing practices, and it discourages waste. While experiments indicate that a few ISPs still try to filter at the /22 boundary, I have been repeatedly told that most don't filter anything shorter than a /24. While routing policy and allocation policies don't need to necessarily match, it is not unreasonable to have them in alignment. In addition, by keeping the PI allocation size for multi-homed organizations at /22, organizations seeking PI space that don't meet the requirements may be encouraged to exaggerate their address usage. This is something that should clearly not be encouraged. On the topic of routing slots, I would like to note that any org qualifying under the PI policies in 4.3.2.2 would also qualify for PA space, and would likely have an interest in multi-homing regardless of the usage of PA vs. PI space. In either instance, a routing slot is consumed by a /24. This policy change should therefore have minimal, if any, impact on the size of the global routing table. It merely gives organizations more options at a slightly smaller network size. Remember that for consideration under 4.3.2.2, an organiztion *must* be multi-homed. On a side note, it's tempting to remove the restriction entirely. If an organization only qualifies for a /28 (for example), they could receive an allocation of that size. Market forces would decide if that /28 was worth a routing slot. If the /28 contained my personal website, I suspect it would not be routable. If that /28 contained Microsoft Update, I suspect it would. In the interest of operational sanity and simplicity, I am not making a proposal to remove the restriction. (Note that section 4.1.1 explicitly notes that PI addresses are not guaranteed to be globally routable.) There is fundamental conflict between the urge for aggregation and the desire for conservation. The latter would prefer that organizations not have any excess space, while the former would prefer that fewer networks exist in the DFZ, regardless of wastage. Since the DFZ already permits deaggregation to /24, the conservation urge should be allowed to push to that edge. As noted in 4.1.5, "determination of IP address allocation size is the responsibility of ARIN." This proposal simply allows the community to request appropriately sized blocks, and ARIN to allocate prefixes of a size that is commensurate with established need. Timetable for implementation: immediate From info at arin.net Wed Apr 25 16:02:05 2007 From: info at arin.net (Member Services) Date: Wed, 25 Apr 2007 16:02:05 -0400 Subject: Policy Proposal 2007-7 - Last Call Message-ID: <462FB3BD.8060806@arin.net> Policy Proposal 2007-7 Creation of Policy for Subsequent End-User IP Requests/Assignments The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that there is community consensus in favor of the proposal and moved it to last call. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 24 April 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XIX/mem.html The AC edited the last sentence; they changed the NRPM section reference from "...policies 4.3.2, and 4.3.3." to "...the policies found in Section 4.3 of the NRPM." The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_7.html Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 23:59, Eastern Time, 9 May 2007. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-7 Creation of Policy for Subsequent End-User IP Requests/Assignments Proposal type: New Policy term: Permanent Policy statement: 4.3.6 Additional Assignments In order to justify an additional assignment, end-users must have efficiently utilized at least 80% of all previous assignments, and must provide ARIN with utilization details. The prefix size for an additional assignment is determined by applying the policies found in Section 4.3 of the NRPM. Rationale: There are no published criteria for additional assignment requests from end-user networks. NRPM 4.3 seems to only cover initial assignments. NRPM 4.3.3 states, in part, "Requesters must show exactly how previous address assignments have been utilized and must provide appropriate details to verify their one-year growth projection." Unfortunately, the above text does not specify any metrics for ARIN staff to apply when determining if an additional assignment is justified. Though most end-users only get one assignment, some end-users request a 2nd or 3rd or Nth assignment. Currently, the ARIN staff applies what they perceive to be "efficient utilization" criteria; for instance, the end-user must have utilized at least 80% of last assignment and must provide ARIN with utilization details. Timetable for implementation: Immediate From info at arin.net Wed Apr 25 16:02:14 2007 From: info at arin.net (Member Services) Date: Wed, 25 Apr 2007 16:02:14 -0400 Subject: Policy Proposal 2007-8 - Last Call Message-ID: <462FB3C6.8020205@arin.net> Policy Proposal 2007-8 Transfer Policy Clarifications The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that there is community consensus in favor of the proposal and moved it to last call. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 24 April 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XIX/mem.html The AC edited one instance of "address space" to "number resources." The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_8.html Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 23:59, Eastern Time, 9 May 2007. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ##*## Policy Proposal 2007-8 Transfer Policy Clarifications Proposal type: Modify Policy term: Permanent Policy statement: That Section 8 of the NRPM is replaced as follows: 8. Transfers 8.1. Transfers Number resources are non-transferable and are not assignable to any other organization unless ARIN has expressly and in writing approved a request for transfer. ARIN is tasked with making prudent decisions on whether to approve the transfer of number resources. It should be understood that number resources are not "sold" under ARIN administration. Rather, number resources are assigned to an organization for its exclusive use for the purpose stated in the request, provided the terms of the Registration Services Agreement continue to be met and the stated purpose for the number resources remains the same. Number resources are administered and assigned according to ARIN's published policies. Number resources are issued, based on justified need, to organizations, not to individuals representing those organizations. Thus, if a company goes out of business, regardless of the reason, the point of contact (POC) listed for the number resource does not have the authority to sell, transfer, assign, or give the number resource to any other person or organization. The POC must notify ARIN if a business fails so the assigned number resources can be returned to the available pool of number resources if a transfer is not requested and justified. 8.2. Transfer Requirements ARIN will consider requests for the transfer of number resources only upon receipt of evidence that the new entity has acquired the assets which had, as of the date of the acquisition or proposed reorganization, justified the current entity's use of the number resource. Examples of assets that justify use of the number resource include, but are not limited to: * Existing customer base * Qualified hardware inventory * Specific software requirements. 8.3. Documentation Requirements In evaluating a request for transfer, ARIN may require the requesting organization to provide any of the following documents, as applicable, plus any other documents deemed appropriate: * An authenticated copy of the instrument(s) effecting the transfer of assets, e.g., bill of sale, certificate of merger, contract, deed, or court decree * A detailed inventory of all assets utilized by the requesting party in maintaining and using the number resource * A list of the requesting party's customers using the number resources If further justification is required, the requesting party may be asked to provide any of the following, or other supporting documentation, as applicable: * A general listing of the assets or components acquired * A specific description of acquisitions, including: o Type and quantity of equipment o Customer base * A description of how number resources are being utilized * Network engineering plans, including: o Host counts o Subnet masking o Network diagrams o Reassignments to customers Policy Rationale Staff analysis and community comments have a problem with the inconsistent use of the terms "ASN" and "IP Address" in this section which leads to confusion on which resources can be transferred. The entire section now utilizes the term "number resources" to clarify what would appear to be the original intent. A section regarding the handling of customer networks outside ARIN's geographic region has been removed to reflect the actual current procedure utilized that was developed in conjunction with the ERX transfer project. The last section of old text has been removed as it does not appear to be so much policy as guidance. Timetable for implementation: Immediate From info at arin.net Wed Apr 25 16:02:23 2007 From: info at arin.net (Member Services) Date: Wed, 25 Apr 2007 16:02:23 -0400 Subject: Policy Proposal 2007-9 - Last Call Message-ID: <462FB3CF.8000401@arin.net> Policy Proposal 2007-9 Modernization of ISP Immediate Need Policy The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that there is community consensus in favor of the proposal and moved it to last call. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 24 April 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XIX/mem.html The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_9.html Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 23:59, Eastern Time, 9 May 2007. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ##*## Policy Proposal 2007-9 Modernization of ISP Immediate Need Policy Proposal type: modify Policy term: permanent Policy statement: Modify NRPM 4.2.1.6 to read: If an ISP has an immediate need for address space, and can provide justification to show that the address space will be utilized within 30 days of the request, ARIN may issue a block of address space, not larger than a /16 nor smaller than ARIN's customary minimum allocation, to that organization. These cases are exceptional. Current text of 4.2.1.6: If an ISP has an immediate need for address space, i.e., the need exists the day of the request, ARIN may issue a /20 if the organization, such as a new company, shows justification. However, these cases are exceptional. Rationale: ARIN staff and ARIN members have identified a few long-standing problems with the Immediate Need policy. This policy proposal attempts to address the following concerns: * The Immediate Need policy only allows ISPs to qualify for a /20 worth of space, when a larger size block may be necessary to provide proper coverage for the proposed project. An example justifying larger space is an MSOs for which a /20 is insufficient to put an address block larger than a /29 or /30 on each CMTS in a metropolitan area). * Conversely, this policy was written before the current multi-homed policy (which allows allocations of /21s and /22s). The Immediate Need policy should allow assignment of smaller blocks of space if those are justified. * The example used in the Immediate Need policy gives the impression that an immediate need must exist the day of the request. This seems both unfair and unreasonable and should probably be changed to reflect a realistic timeframe. Concerns expressed about the Immediate Need Policy but NOT addressed by this policy proposal (but addressed in a subsequent policy proposal): * The policy as written allows ARIN to issue a /20 to an ISP only. However, section 4.3.4. "Additional Considerations" of the End User Policy in the NRPM states that "End-users may qualify for address space under other policies such as Immediate need [4.2.1.6] or Micro-allocation [4.4].". In order to be consistent, the Immediate Need policy language should be changed to reflect the fact that both ISPs and end-users can qualify under this policy. Timetable for implementation: Immediate From info at arin.net Wed Apr 25 16:02:34 2007 From: info at arin.net (Member Services) Date: Wed, 25 Apr 2007 16:02:34 -0400 Subject: Policy Proposal 2007-11 - Last Call Message-ID: <462FB3DA.8000001@arin.net> Policy Proposal 2007-11 Refinement of ISP Initial Allocation Policy The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that there is community consensus in favor of the proposal and moved it to last call. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 24 April 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XIX/mem.html The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_11.html Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 23:59, Eastern Time, 9 May 2007. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ##*## Policy Proposal 2007-11 Refinement of ISP Initial Allocation Policy Policy statement Proposal type: modify Policy term: permanent Policy statement: In NRPM 4.2.4.3 (Initial Allocations to ISPs Policy), strike the following sentence: "When completing Section 7 of the ARIN ISP Network Request Template, please keep this in mind" Rationale: Instructions on filling out templates properly belong in the instructions attached to the template, not as part of a policy statement. This reminder makes reference to an obsolete template and section. ARIN released new templates in August 2006 and changed template names, field numbers, and sections which made both of these references obsolete. Timetable for implementation: Immediate From info at arin.net Wed Apr 25 16:02:43 2007 From: info at arin.net (Member Services) Date: Wed, 25 Apr 2007 16:02:43 -0400 Subject: Policy Proposal 2007-10 - Abandoned Message-ID: <462FB3E3.4090704@arin.net> Policy Proposal 2007-10 End Site Immediate Need Policy The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that there is not community consensus in favor of the proposal and abandoned it. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 24 April 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XIX/mem.html The AC felt that a fresh new start would be best to address concerns put forward on the mailing list and at the microphone. In order for this proposal to be further considered the author must use the last call petition process as defined in the ARIN Internet Resource Policy Evaluation Process. This policy will be considered to be abandoned if the author of the proposal does not initiate a last call petition by 23:59, Eastern Time, 2 May 2007. The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_10.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ##*## Policy Proposal 2007-10 End Site Immediate Need Policy Proposal type: new Policy term: permanent Policy statement: Create new section in NRPM 4.3.6. to mirror the intent of 4.2.1.6, but modified for end sites. If pending proposal "Modernization of ISP Immediate Need Policy" is ratified, this new section will read: 4.3.6 Immediate Need: If an end-user has an immediate need for address space, and can provide justification to show that the address space will be utilized within 30 days of the request, ARIN may issue a block of address space, not larger than a /16 nor smaller than ARIN's customary minimum allocation, to that organization. These cases are exceptional. In the absence of ratification of ""Modernization of ISP Immediate Need Policy", this proposal is to add section 4.3.6 with a modification of the current text of 4.2.1.6 to make it apply to end-users: 4.3.6 Immediate Need: If an end-user has an immediate need for address space, i.e., the need exists the day of the request, ARIN may issue a /20 if the organization, such as a new company, shows justification. However, these cases are exceptional. Rationale: ARIN staff has expressed the concern that the current policy is self-contradictory, in one place stating that the Immediate Need Policy applies to ISPs, and in another place stating that end users can qualify under it. The communication received was: * The policy as written allows ARIN to issue a /20 to an ISP only. However, section 4.3.4. "Additional Considerations" of the End User Policy in the NRPM states that "End-users may qualify for address space under other policies such as Immediate need [4.2.1.6] or Micro-allocation [4.4].". In order to be consistent, the Immediate Need policy language should be changed to reflect the fact that both ISPs and end-users can qualify under this policy. Timetable for implementation: Immediate From info at arin.net Wed Apr 25 16:02:52 2007 From: info at arin.net (Member Services) Date: Wed, 25 Apr 2007 16:02:52 -0400 Subject: Policy Proposal 2007-12 - Abandoned Message-ID: <462FB3EC.9060303@arin.net> Policy Proposal 2007-12 IPv4 Countdown Policy Proposal The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that there is not community consensus in favor of the proposal and abandoned it. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 24 April 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XIX/mem.html The AC noted that this subject still needs to be looked at for other possible policy creation. In order for this proposal to be further considered the author must use the last call petition process as defined in the ARIN Internet Resource Policy Evaluation Process. This policy will be considered to be abandoned if the author of the proposal does not initiate a last call petition by 23:59, Eastern Time, 2 May 2007. The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_12.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ##*## Policy Proposal 2007-12 IPv4 Countdown Policy Proposal Proposal type: new Policy term: renewable Policy statement: - Set the date for termination of (IPv4) allocations and the date of announcement Set the date to terminate allocations as a general rule, and announce it a certain period in advance. Define the date of announcement as "A-date" and the date to terminate allocations as "T-date". The two dates will be set as follows: A-date (Date of Announcement): - The day in which the IANA pool becomes less than 30*/8 - RIRs must announce "T-date" on this day, which is defined later (*) There will be no changes in the policy on A-date T-date(Date of Termination): - Exactly two years after A-date - 10*/8 blocks should remain at T-date, and defined as two years after A-date, based on the current pace of allocations - It is however possible to move T-date forward at the point where address consumpution exceeds the projections during the course of two years (*) new allocations/assignments from RIRs should terminate on T-date as a general rule. Allocations or assignments to "critical infrastructure" after T-date should be defined by a separate policy. Rationale: 1. Introduction The exhaustion of IPv4 address is approaching round the corner. Geoff Huston's latest projection at Potaroo (as of January 6, 2007) (http://www.potaroo.net/tools/ipv4/) draws the date of IANA pool exhaustion as 31st May 2011, and that of RIR pool as 14th July 2012. Tony Hain projects similar dates based on a different algorithm of his own. From these data, we may observe that if that the current allocation trend continues, the exhaustion of IPv4 address space is expected to take place as early as within the next five years. ICANN/IANA and RIRs must co-ordinate with stakeholders to achieve smooth termination of IPv4 address space as the Internet bodies responsible for stable management and distribution of IP number resources. This proposal provides some ideas as well as concrete examples of the policy that helps IPv4 allocations come to an end with "the minimum confusion" and in "as fair manner as possible". "Five years at the earliest" is not too far in the future for the exhaustion of IPv4 address space. Assuming the minimum of one year is required for sufficient policy discussions with this proposal as a start, and two years for preparation and transfer by LIRs, we need to start the discussions right at this time. 2. Summary of current problems Despite the fact that several projections are made on IPv4 address to run out as early as within the next few years, no discussions are taking place on any of the RIR's policy fora. (we have submitted the same proposal to APNIC on January 2007) This section lists possible problems if no policies are defined to prepare for the terminal period of allocations. 2-1. LIR LIRs currently do not consider IPv4 address exhaustion as an imminent issue in the first place. It is possible that they will finally realize the situation only when impacts of the exhaustion becomes visible as a practical matter, and lead to confusions such as re-addressing their network or making subsequent requests at the last minute in within a limited time frame. There could also be cases where allocations blocks cannot be allocated to some of the LIRs even though requests are submitted on the same day. Moreover, although it would be necessary for LIRs to announce to their customers that IPv4 address space will not be available for assignments eventually, it is difficult to plan this timing without clear policy for the last phase of allocations. As new IPv4 address allocations space will no longer be available, LIRs have no choice but to build networks based on IPv6. However, there are risks of trouble if preparations are made from that point in time, as it will lead to premature actions even if some time can be bought by re-addressing and subsequent allocations. Lastly, using up all available IPv4 address space will disable assignments to services inevitable for co-existence of IPv4 and IPv6 networks, such as the translator service between the two networks, which it may create situation where transfer to IPv6 network will not even be possible. 2-2. RIR/NIR It is likely that smooth allocations by RIRs/NIRs will be hindered by rush of inquiries during the terminal phase of allocations. 2-3. End users End users generally receive address assignments from ISPs accompanied with Internet connection service. If an ISP no longer has IPv4 address space available, nor unable to provide IPv6 service, end users will not be able to receive services from that ISP. Moreover, if the terminal date of allocations remains ambiguous, it may leave end users behind to prepare for IPv6 ready network. 3. Benefits There will be the following benefits by implementing the policy for IPv4 address exhaustion as proposed on this paper. 3-1. LIR LIRs will be able to consciously plan their addressing within their networks if the final date of allocations is clearly demonstrated. Keeping a certain amount of unallocated address blocks enables allocations/assignments for "critical infrastructure" after the termination of regular allocations, which will be explained later section in more details. 3-2. RIR/NIR Announcing the date of terminating allocations in advance and ensuring that all allocations before this date will be made according to the policy at the time enables RIRs/NIRs to make the last allocation without confusions and avoids causing feelings of unfairness among LIRs and end users. In addition, consistent policy applied to all RIRs removes bias towards certain region as well as inter-regional unfairness. The period which IPv6 support is completed becomes clear, therefore, RIRs/NIRs can prepare for this. 3-3. End user As this proposal enables LIRs to prepare for the terminal period of allocations in advance, it reduces the risk of delays/ suspensions of assignments from LIRs to enduers, and end users will be able to continuously receive services from LIRs. As in the case of LIRs, end users will be able to prepare for IPv6 support by the date of allocation termination is clarified. In addition, IPv6 connectivity as well as IPv4 address required during the allocation termination period will be smoothly secured by LIRs preparing for such period. As listed above, there will be important, notable benefits for stakeholders as a result of this policy. It is therefore necessary to take the following actions to achieve a smooth transfer to IPv6 and prevent causing instability in the Internet as well as; - start discussions on allocation scheme during the exhaustion period, - indicate a roadmap to exhaustion after raising awareness on the issue, and - allow enough time for LIRs to plan timing of addressing of their networks, submit allocation requests, and consider how to switch to IPv6. 4. Proposal principles As the first step to discuss IPv4 exhaustion planning, we would like to have an agreement(consensus) on the following four principles. -------------------------------------------------------------------- (1) Global synchronization: All five RIRs will proceed at the same time for measures on IPv4 address exhaustion. (2) Some Blocks to be left: Keep a few /8 stocks instead of distributing all. (3) Keeping current practices until the last moment : Maintain the current policy until the last allocation. (4) Separate discussions on "Recycle" issue : Recovery of unused address space should be discussed separately. -------------------------------------------------------------------- (1) Global synchronization: All RIRs must proceed at the same time to take measures for IPv4 address exhaustion. This is important not only for ensuring fairness for LIRs across the regions, but alsot to prevent confusions such as attempts to receive allocations from an RIR outside their region. The five RIRs should facilitate bottom-up discussions, which should be well coordinated under the leaderships of ICANN ASO and NRO. (2) Some blocks to be left: It is not practical to consider that IPv4 address blocks can be allocated to the last piece. It is expected to cause confusions if one party can receive an allocation while the other has to give up, just with a touch of a difference. The best solution to avoid such confusion is to set in advance, a date in which one is able to receive an allocation if requests are submitted before this timeline. Furthermore, there are few cases where allocations or assignments of IPv4 address space become absolutely necessary in the future. For example, requirements to start a translator service between IPv4 and IPv6 networks should be supported, and there may be some requirements in the future that are beyond our imagination at this current moment. As such, a date to stop allocations under the current policy should be set/defined so that certain number of IPv4 address blocks will be kept as stocks instead of allocating all blocks without remains. (3) Maintaining current practices until the last moment : Allocations should be made based on the current policy until the time to terminate allocations. As the IPv4 Internet has now developed into a social infrastructure supporting large number of businesses, making large changes in the current policy towards conservation within the next one or two years will lead to large-scale confusions, and difficult in the reality. (4) Separate discussion from "Recycle" issue Recovering unused allocated/assigned address blocks is an important measure, and in fact, it has already be discussed and implemented in each RIR regions. This issue, however should be considered separately from this proposal as recovery of a few /8 blocks extends the lifetime of IPv4 for less than one year while efforts for the recovery is expected to require substantial time. 5. Rationale for "A-date" & "T-date" A-date is set in order to: - Allow some grace period and period for networks to be IPv6 ready until the termination of allocations. - Prevent unfairness among LIRs by clarifying the date, such as not being able to receive allocations by a small difference in timing. The rationale for setting A-date as "when IANA pool becomes less than 30*/8" is as follows: The rate of allocations from IANA to RIRs after 2000 is as follows. 2000 : 4*/8 2001 : 6*/8 2002 : 4*/8 2003 : 5*/8 2004 : 9*/8 2005 : 13*/8 2006 : 10*/8 Approximately 10*/8 has been allocated annually after 2003, and the consumption is likely to accelerate with rise of the last minute demands. As it is better to keep minimum stocks of address pool at IANA, 30*/8 is set as the threshold value, and allocations should be terminated two years after it reaches the value, which ensures that IANA/RIRs secure the address space for allocations/assignments to critical infrastructure. 6. Effect on RIR members RIR members are expected to concretely grasp the termination date of allocations and take actions within their organization to prepare for the event. Timetable for implementation: Immediate after all 5 RIRs ratified this policy.