From info at arin.net Sat Feb 10 08:47:32 2007 From: info at arin.net (Member Services) Date: Sat, 10 Feb 2007 08:47:32 -0500 Subject: Policy Proposal: Removal of Ipv6 Operational Information from NRPM Message-ID: <45CDCCF4.6040008@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 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 Ipv6 Operational Information from NRPM Authors: Lea Roberts Cathy Aronson Proposal Version: Version 0 Submission Date: 8 February 2007 Proposal type: Modify Policy term: Permanent Policy statement: The following parts of Section 6.5.4.1 should be removed from the Number Resource Policy Manual (NRPM). NRPM Section 6.5.4.1 states: The following guidelines may be useful (but they are only guidelines): * /64 when it is known that one and only one subnet is needed * /56 for small sites, those expected to need only a few subnets over the next 5 years. * /48 for larger sites Rationale: Discussions in recent public policy meetings, as well as in Advisory Council meetings, have led to the consensus that operational information, such as these IPv6 guidelines, should be removed from the NRPM. This section is a clear example of text not directly related to ARIN policy and so it is proposed that it should be removed. Timetable for implementation: Immediate From info at arin.net Thu Feb 15 10:00:42 2007 From: info at arin.net (Member Services) Date: Thu, 15 Feb 2007 10:00:42 -0500 Subject: Deadline for Policy Proposals - 22 February 2007 Message-ID: <45D4759A.7070200@arin.net> The ARIN XIX Public Policy Meeting will take place 23-24 April 2007 in San Juan, Puerto Rico. New policy proposals must be submitted by 23:59 EST, 22 February 2007, in order to be considered by the ARIN Advisory Council for possible inclusion on the ARIN XIX agenda. This is in accordance with ARIN's Internet Resource Policy Evaluation Process, which requires that proposed policies be submitted at least 60 days prior to the meeting. Those who wish to propose new ARIN number resource policies or modifications to existing policies must submit a Policy Proposal Template. The template must be sent via e-mail to policy at arin.net. The Policy Proposal Template can be found at: http://www.arin.net/policy/irpep_template.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) From info at arin.net Thu Feb 15 10:08:45 2007 From: info at arin.net (Member Services) Date: Thu, 15 Feb 2007 10:08:45 -0500 Subject: Policy Proposal: IPv4 PI minimum size change Message-ID: <45D4777D.4070407@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 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: IPv4 PI minimum size change Author: David Williamson Proposal Version: 1.0 Submission Date: 2/14/2007 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 Feb 16 17:06:07 2007 From: info at arin.net (Member Services) Date: Fri, 16 Feb 2007 17:06:07 -0500 Subject: Policy Proposal: Creation of Policy for Subsequent End-User IP Requests/Assignments Message-ID: <45D62ACF.3030902@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 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: Creation of Policy for Subsequent End-User IP Requests/Assignments Author: Alex Rubenstein Proposal Version: 1 Submission Date: 15 February 2007 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 Feb 16 17:21:32 2007 From: info at arin.net (Member Services) Date: Fri, 16 Feb 2007 17:21:32 -0500 Subject: Policy Proposal: eGLOP multicast address assignments Message-ID: <45D62E6C.1060506@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 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: eGLOP multicast address assignments Author: Marshall Eubanks David Meyer Proposal Version: 1 Submission Date: 15 February 2007 Proposal type: new Policy term: permanent Policy statement: RFC 2770 [now replaced by RFC 3180 / BCP 53] set up an automatic "GLOP" multicast address assignment in 233/8 based on Autonomous System Numbers (ASNs). The mechanism that was set up in RFC 3180 for extending GLOP assignments, known as eGLOP, envisioned the assignment of multicast addresses by RIRs from the portion of the 233/8 space corresponding to the RFC 1930 private address space. This mechanism has never been used, but its use has now imperative due to both an increased interest in multicast address assignments to support IPTV and the adopted proposals to assign 4-octet ASNs, which do not have GLOP assignments. This proposal is for the assignment of Multicast addresses by the ARIN RIR using the criteria set up in RFC 3180; equivalent proposals are being sent to the other RIRs for their consideration. Rationale: RFC 2770 [now replaced by RFC 3180 / BCP 53] set up an automatic "GLOP" multicast address assignment in 233/8 based on Autonomous System Numbers (ASNs). The mechanism that was set up in RFC 3180 for extending GLOP assignments, known as eGLOP, envisioned the assignment of multicast addresses by RIRs from the portion of the 233/8 space corresponding to the RFC 1930 private address space. This mechanism has never been used, but its use has now imperative due to both an increased interest in multicast address assignments to support IPTV and the adopted proposals to assign 4-octet ASNs, which do not have GLOP assignments. This proposal is for the assignment of Multicast addresses by the APNIC RIR; equivalent proposals will be sent to the other RIRs for consideration in due course. RFC 2770 and RFC 3180 describe an experimental policy for use of the class D address space by mapping 16 bits of Autonomous System number (AS) into the middle two octets of 233/8 to yield a /24, which is automatically assigned to that ASN. While this technique has been successful, the assignments are inefficient in those cases in which a /24 is too small or the user doesn't have its own AS, and it does not work for 4-octet AS number extension scheme. RFC 3138 expanded on RFC 2770 to allow routing registries to assign multicast addresses from the GLOP space corresponding to the RFC 1930 private AS space; referred to as the EGLOP (Extended GLOP) address space. The failure to instantiate RFC 3138 assignments had lead to a situation where some multicast users feel like they cannot obtain addresses, while others apply directly to IANA, with there being at least 24 approved applications in 2006. The current situations in inequitable and inefficient and there is no reason not to apply the mechanism set up in RFC 3138. RFC 3138 allocated 233.252/14 to eGLOP. The RFC further says that: Globally scoped IPv4 multicast addresses in the EGLOP space are assigned by a Regional Registry (RIR). An applicant MUST, as per [IANA], show that the request cannot be satisfied using Administratively Scoped addressing [RFC2365], GLOP addressing [RFC2770], or SSM. The fine-grained assignment policy is left to the assigning RIR. We propose that each RIR be allocated an initial /20 from this address range, and allocate by default /28's to proposers (16 addresses as Multicast address are not subject to CIDR default restrictions), subject to the above criteria, and that the RIR assign more addresses based on demonstrated need. (Note that Multicast addresses are not subject to classless aggregation and address blocks as small as a /32 can be usefully assigned.) The proposed policy should facilitate multicast deployment. The current mechanism for non-GLOP multicast deployment involves requesting an assignment from IANA, which has no ability to evaluate these requests and relies on the IANA Multicast Expert appointed by the IESG (currently David Meyer). This process is inefficient, inequitable (as this policy route is not widely known), encourages the use of "rogue" self- assignments, and discourages application developers and service providers from developing and deploying multicast. The only disadvantage that we can see from the proposed policy is that the RIR's will have to set up and execute mechanisms to implement it. Effect on APNIC: We feel that adoption of this proposal will help to make multicast deployment more widespread, and should be of benefit to APNIC members adopting Multicast for video distribution on the Internet. References ---------- [IANA] http://www.iana.org/assignments/multicast-addresses [RFC1930] Hawkinson, J., and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", RFC 1930, March 1996. [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, July 1998. [RFC2770] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", RFC 2770, February 2000. [RFC3138] Meyer, D., "Extended Assignments in 233/8", RFC 3138, June 2001. [RFC3180] Meyer, D., "GLOP Addressing in 233/8", BCP 53, RFC 3180, September 2001. Timetable for implementation: Immediately From info at arin.net Fri Feb 16 17:48:22 2007 From: info at arin.net (Member Services) Date: Fri, 16 Feb 2007 17:48:22 -0500 Subject: Policy Proposal 2007-1: Reinstatement of PGP Authentication Method Message-ID: <45D634B6.8090600@arin.net> On 15 February 2007 the ARIN Advisory Council (AC) concluded its review of 'Reinstatement of PGP Authentication Method' and accepted it as a formal policy proposal for discussion by the community. The proposal is designated Policy Proposal 2007-1: Reinstatement of PGP Authentication Method. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2007_1.html All persons in the community are encouraged to discuss Policy Proposal 2007-1 prior to it being presented at the ARIN Public Policy Meeting in San Juan, Puerto Rico, 23-24 April 2007. Both the discussion on the Public Policy Mailing List and at the Public Policy Meeting will be used to determine the community consensus regarding this policy proposal. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html ARIN's Policy Proposal Archive can be found at: http://www.arin.net/policy/proposals/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-1: Reinstatement of PGP Authentication Method Authors: Paul Vixie, Mark Kosters, Chris Morrow, Jared Mauch, Bill Woodcock 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. 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 Feb 16 17:56:38 2007 From: info at arin.net (Member Services) Date: Fri, 16 Feb 2007 17:56:38 -0500 Subject: Policy Proposal 2007-2: Documentation of the Mail-From Authentication Method Message-ID: <45D636A6.2050502@arin.net> On 15 February 2007 the ARIN Advisory Council (AC) concluded its review of 'Documentation of the Mail-From Authentication Method' and accepted it as a formal policy proposal for discussion by the community. The proposal is designated Policy Proposal 2007-2: Documentation of the Mail-From Authentication Method. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2007_2.html All persons in the community are encouraged to discuss Policy Proposal 2007-2 prior to it being presented at the ARIN Public Policy Meeting in San Juan, Puerto Rico, 23-24 April 2007. Both the discussion on the Public Policy Mailing List and at the Public Policy Meeting will be used to determine the community consensus regarding this policy proposal. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html ARIN's Policy Proposal Archive can be found at: http://www.arin.net/policy/proposals/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## 2007-2: Documentation of the Mail-From Authentication Method Authors: Paul Vixie, Mark Kosters, Chris Morrow, Jared Mauch, Bill Woodcock 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 Feb 16 17:56:49 2007 From: info at arin.net (Member Services) Date: Fri, 16 Feb 2007 17:56:49 -0500 Subject: Policy Proposal 2007-3: Documentation of the X.509 Authentication Method Message-ID: <45D636B1.8090207@arin.net> On 15 February 2007 the ARIN Advisory Council (AC) concluded its review of 'Documentation of the X.509 Authentication Method' and accepted it as a formal policy proposal for discussion by the community. The proposal is designated Policy Proposal 2007-3: Documentation of the X.509 Authentication Method. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2007_3.html All persons in the community are encouraged to discuss Policy Proposal 2007-3 prior to it being presented at the ARIN Public Policy Meeting in San Juan, Puerto Rico, 23-24 April 2007. Both the discussion on the Public Policy Mailing List and at the Public Policy Meeting will be used to determine the community consensus regarding this policy proposal. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html ARIN's Policy Proposal Archive can be found at: http://www.arin.net/policy/proposals/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-3: Documentation of the X.509 Authentication Method Authors: Paul Vixie, Mark Kosters, Chris Morrow, Jared Mauch, Bill Woodcock 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 Feb 16 18:06:12 2007 From: info at arin.net (Member Services) Date: Fri, 16 Feb 2007 18:06:12 -0500 Subject: Policy Proposal 2007-4: Changes to IPv6 policy - removal of "interim" consideration Message-ID: <45D638E4.5080405@arin.net> On 15 February 2007 the ARIN Advisory Council (AC) concluded its review of 'Changes to IPv6 policy - removal of "interim" consideration' and accepted it as a formal policy proposal for discussion by the community. The proposal is designated Policy Proposal 2007-4: Changes to IPv6 policy - removal of "interim" consideration. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2007_4.html All persons in the community are encouraged to discuss Policy Proposal 2007-4 prior to it being presented at the ARIN Public Policy Meeting in San Juan, Puerto Rico, 23-24 April 2007. Both the discussion on the Public Policy Mailing List and at the Public Policy Meeting will be used to determine the community consensus regarding this policy proposal. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html ARIN's Policy Proposal Archive can be found at: http://www.arin.net/policy/proposals/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-4: Changes to IPv6 policy - removal of "interim" consideration Author: Jordi Palet Martinez 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 Feb 16 18:06:20 2007 From: info at arin.net (Member Services) Date: Fri, 16 Feb 2007 18:06:20 -0500 Subject: Policy Proposal 2007-5: Changes to IPv6 policy - removal of "multiple /48" justification Message-ID: <45D638EC.2060308@arin.net> On 15 February 2007 the ARIN Advisory Council (AC) concluded its review of 'Changes to IPv6 policy - removal of "multiple /48" justification' and accepted it as a formal policy proposal for discussion by the community. The proposal is designated Policy Proposal 2007-5: Changes to IPv6 policy - removal of "multiple /48" justification. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2007_5.html All persons in the community are encouraged to discuss Policy Proposal 2007-4 prior to it being presented at the ARIN Public Policy Meeting in San Juan, Puerto Rico, 23-24 April 2007. Both the discussion on the Public Policy Mailing List and at the Public Policy Meeting will be used to determine the community consensus regarding this policy proposal. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html ARIN's Policy Proposal Archive can be found at: http://www.arin.net/policy/proposals/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-5: Changes to IPv6 policy - removal of "multiple /48" justification Author: Jordi Palet Martinez 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 Feb 16 18:16:01 2007 From: info at arin.net (Member Services) Date: Fri, 16 Feb 2007 18:16:01 -0500 Subject: Policy Proposal 2006-7: Changes to IPv6 initial allocation criteria - revised text Message-ID: <45D63B31.3010100@arin.net> Policy Proposal 2006-7: Changes to IPv6 initial allocation criteria has been revised. This proposal is open for discussion on this mailing list and will be on the agenda at the upcoming ARIN Public Policy Meeting. The current policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2006_7.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2006-7: Changes to IPv6 initial allocation criteria - revised text Author: Jordi Palet Martinez Proposal Version: 2 Submission Date: 16 February 2007 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 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 implimented 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 Thu Feb 22 10:59:06 2007 From: info at arin.net (Member Services) Date: Thu, 22 Feb 2007 10:59:06 -0500 Subject: Policy Proposal: IPv4 countdown policy proposal Message-ID: <45DDBDCA.6060405@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 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: IPv4 countdown policy proposal Author: Toshiyuki Hosaka (Japan Network Information Center (JPNIC)) Co-Authors: Takashi Arano (Intec Netcore, Inc.) Kuniaki Kondo (Atelier Mahoroba) Tomohiro Fujisaki (NTT) Akinori Maemura (JPNIC) Kosuke Ito (IRI Ubitech) Shuji Nakamura (IPv6 Promotion Council) Tomoya Yoshida (NTT Communications) Susumu Sato (JPNIC) Akira Nakagawa (KDDI) Proposal Version: 1 Submission Date: 22 February 2007 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 Thu Feb 22 20:59:53 2007 From: info at arin.net (Member Services) Date: Thu, 22 Feb 2007 20:59:53 -0500 Subject: Policy Proposal: Transfer Policy Clarifications Message-ID: <45DE4A99.7070207@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 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: Transfer Policy Clarifications Author: Paul Andersen Proposal Version: 1.0 Submission Date: February 22, 2007 Proposal type: Modify Policy term: Permanent Policy statement: That Section 8 of the NRPM is replaced as follows: 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: * Type and quantity of equipment * Customer base * A description of how address space is being utilized * Network engineering plans, including: * Host counts * Subnet masking * Network diagrams * Reassignments to customers 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 Thu Feb 22 22:38:19 2007 From: info at arin.net (Member Services) Date: Thu, 22 Feb 2007 22:38:19 -0500 Subject: Policy Proposal: Modernization of ISP Immediate Need Policy Message-ID: <45DE61AB.4080708@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 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: Modernization of ISP Immediate Need Policy Author: Robert Seastrom Proposal Version: 1.0 Submission Date: 22-Feb-2007 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 Thu Feb 22 22:38:49 2007 From: info at arin.net (Member Services) Date: Thu, 22 Feb 2007 22:38:49 -0500 Subject: Policy Proposal: End Site Immediate Need Policy Message-ID: <45DE61C9.1040507@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 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: End Site Immediate Need Policy Author: Robert Seastrom Proposal Version: 1.0 Submission Date: 22-Feb-2007 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 Thu Feb 22 22:39:30 2007 From: info at arin.net (Member Services) Date: Thu, 22 Feb 2007 22:39:30 -0500 Subject: Policy Proposal: Refinement of ISP Initial Allocation Policy Message-ID: <45DE61F2.9060907@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 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: Refinement of ISP Initial Allocation Policy Author: Robert Seastrom Proposal Version: 1.0 Submission Date: 22-Feb-2007 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 Feb 23 14:06:59 2007 From: info at arin.net (Member Services) Date: Fri, 23 Feb 2007 14:06:59 -0500 Subject: ARIN XIX Meeting Registration Open Message-ID: <45DF3B53.5010005@arin.net> ARIN invites you to attend the ARIN XIX Public Policy and Members Meeting, to be held 22-25 April 2007 in San Juan, Puerto Rico. Registration for ARIN XIX is now open. Links to meeting and remote participation information, as well as other meeting information is available at http://www.arin.net/ARIN-XIX/. ARIN holds open, biannual Public Policy and Members Meetings, providing an opportunity for the entire Internet community to contribute to Internet number resource policy discussions and development, network with colleagues, and attend workshops and tutorials. Community participation is the basis of the ARIN policy development process and current policy proposals up for discussion at this meeting are available at: http://www.arin.net/policy/proposals/proposal_archive.html ARIN XIX Overview * Sunday, 22 April - ARIN is excited to offer a "Practical Guide to IPv6 " workshop. This workshop will combine elements of the previous "Getting Started with IPv6" workshops and last fall's "Networking with IPv6" workshop. It will focus on providing hands-on experience using IPv6 on your own laptop and information on IPv6 operations over a network. Sunday activities will also include a lunch for first-time ARIN meeting attendees, a tutorial, an Introduction to IRPEP session, the Open Policy Hour, and the 8th Annual Foosball Tournament. * Monday, 23 April - ARIN Public Policy Meeting, Day 1, evening ARIN Social * Tuesday, 24 April - ARIN Public Policy Meeting, Day 2 * Wednesday, 25 April - ARIN Members Meeting (open to all ARIN XIX attendees) Additional agenda details and more information about ARIN XIX will be posted to our website as we get closer to the meeting, so check back often! Regards, Member Services Department American Registry for Internet Numbers (ARIN) From info at arin.net Mon Feb 26 14:28:43 2007 From: info at arin.net (Member Services) Date: Mon, 26 Feb 2007 14:28:43 -0500 Subject: Notice of PPML Subscription Invitations and Opt-Out Opportunity Message-ID: <45E334EB.9030806@arin.net> Beginning this month, ARIN will send PPML subscription invitations to all registered designated member representatives (DMRs), Admin POCs, and Tech POCs. We realize some of you subscribed to PPML may manage multiple e-mail addresses. Therefore, the invitation will offer a chance to opt out of receiving future PPML subscription invitations. Please contact Member Services at info at arin.net if you have any questions. Regards, Member Services American Registry for Internet Numbers (ARIN)