From cgrundemann at gmail.com Wed Sep 1 14:34:09 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 1 Sep 2010 12:34:09 -0600 Subject: [arin-ppml] Policy Proposal 2010-10 - Global Policy for IPv4 Allocations by the IANA Post Exhaustion In-Reply-To: <4C7C3DF4.8020201@umn.edu> References: <4C7C22B1.2050500@umn.edu> <4C7C3DF4.8020201@umn.edu> Message-ID: On Mon, Aug 30, 2010 at 17:25, David Farmer wrote: > > Chris, I can appreciate you position on this. ?However, I can assure that a > number of the authors of the previous global policy proposal thought that a > mandatory requirement for return was equally important. Understood - I see the return to and allocation from the IANA as two distinct halves of this issue however. > I believe the essential portion of this policy is for IANA to have the > ability to allocate any address space that is returned to it, not just /8s. Agreed. > What address space an RIR returns, if any, or placing restrictions on what > can be done with the space once it is allocated to an RIR is and should be a > local policy concern. I mostly agree with this statement, global policy should only affect global issues. Where I think we differ is that in this particular case I think that the no-transfer clause *is* a global issue, not a local one. Allow me to attempt to explain why: At it's simplest, there are two ways of looking at IPv4 exhaustion and how to deal with the temporary IPv4 address scarcity it is causing: 1) An IPv4 address market will solve everything. 2) Stewardship and generosity will be required. If you are in camp #1, then restricting any addresses from transfers is obviously a bad idea. Beyond that though - this entire policy (which you believe to be essential) is worthless. If paid transfers are going to solve all the worlds IPv4 scarcity problems, then the IANA will never need to worry about fragments - because they will never have any to worry about (since everybody will just sell/rent/whatever IPv4 to each other). If, however, you are in camp #2, then you believe that we should find ways to safeguard against any potential market abuses. Providing alternative means to those who truly need and will use IPv4 addresses to grow the Internet in meaningful ways. In this case, you likely want to see at least some folks (continue to) return unneeded IPv4 addresses. Perhaps especially from the vast tracts of Legacy space, which should be returned directly to the IANA. If we are going to ask our fellow community members to forgo the market and return addresses that they may well be able to sell, then shouldn't we be able to assure them that those same addresses will not be sold by the organization who receives them? Shouldn't they be protected from profiteering if they are to do what we are telling them is the right thing? > I must admit that I would prefer that APNIC transfer policy was needs based, > but that is and should be the APNIC community's choice. ?Just as how ARIN > should deal with address space returned to it should be the ARIN community's > choice. I do not believe that any (at least not many) in the APNIC community wrote their policy to create any of the negatives I have alluded to here. I do think that we should protect against those negatives if we expect anyone to return space to the IANA. If we do not expect anyone to return space - then we don't need a policy for IANA to hand out that space at all. > If we can focus on the essential functions of IANA and stay out of all local > policy issues, I think we might have a policy that can be passed globally. I hope we are close to such a policy. ~Chris > -- > =============================================== > David Farmer ? ? ? ? ? ? ? Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE ? ? ?Phone: 612-626-0815 > Minneapolis, MN 55414-3029 ? Cell: 612-812-9952 > =============================================== > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From owen at delong.com Wed Sep 1 15:22:27 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 2 Sep 2010 05:22:27 +1000 Subject: [arin-ppml] Policy Proposal 2010-10 - Global Policy for IPv4 Allocations by the IANA Post Exhaustion In-Reply-To: References: <4C7C22B1.2050500@umn.edu> <4C7C3DF4.8020201@umn.edu> Message-ID: <8AF80058-D90C-42AD-9443-963C7DF085E5@delong.com> Chris, Consider the following two possibilities: 1. We put forth a policy which can pass in the APNIC region which allows IANA to allocate returned space. 2. We don't get a global policy and the ITU uses that fact as an example of why the RIR system cannot be trusted with such a vital resource. I don't like APNICs transfer policy any more than you do, but I think there is more at stake not having a global policy than the concern about what happens to a few final breadcrumbs of IPv4 or any particular RIR getting more than their share of those crumbs. Owen Sent from my iPad On Sep 2, 2010, at 4:34 AM, Chris Grundemann wrote: > On Mon, Aug 30, 2010 at 17:25, David Farmer wrote: >> >> Chris, I can appreciate you position on this. However, I can assure that a >> number of the authors of the previous global policy proposal thought that a >> mandatory requirement for return was equally important. > > Understood - I see the return to and allocation from the IANA as two > distinct halves of this issue however. > >> I believe the essential portion of this policy is for IANA to have the >> ability to allocate any address space that is returned to it, not just /8s. > > Agreed. > >> What address space an RIR returns, if any, or placing restrictions on what >> can be done with the space once it is allocated to an RIR is and should be a >> local policy concern. > > I mostly agree with this statement, global policy should only affect > global issues. Where I think we differ is that in this particular case > I think that the no-transfer clause *is* a global issue, not a local > one. Allow me to attempt to explain why: > > At it's simplest, there are two ways of looking at IPv4 exhaustion and > how to deal with the temporary IPv4 address scarcity it is causing: > > 1) An IPv4 address market will solve everything. > 2) Stewardship and generosity will be required. > > If you are in camp #1, then restricting any addresses from transfers > is obviously a bad idea. Beyond that though - this entire policy > (which you believe to be essential) is worthless. If paid transfers > are going to solve all the worlds IPv4 scarcity problems, then the > IANA will never need to worry about fragments - because they will > never have any to worry about (since everybody will just > sell/rent/whatever IPv4 to each other). > > If, however, you are in camp #2, then you believe that we should find > ways to safeguard against any potential market abuses. Providing > alternative means to those who truly need and will use IPv4 addresses > to grow the Internet in meaningful ways. In this case, you likely want > to see at least some folks (continue to) return unneeded IPv4 > addresses. Perhaps especially from the vast tracts of Legacy space, > which should be returned directly to the IANA. > > If we are going to ask our fellow community members to forgo the > market and return addresses that they may well be able to sell, then > shouldn't we be able to assure them that those same addresses will not > be sold by the organization who receives them? Shouldn't they be > protected from profiteering if they are to do what we are telling them > is the right thing? > >> I must admit that I would prefer that APNIC transfer policy was needs based, >> but that is and should be the APNIC community's choice. Just as how ARIN >> should deal with address space returned to it should be the ARIN community's >> choice. > > I do not believe that any (at least not many) in the APNIC community > wrote their policy to create any of the negatives I have alluded to > here. I do think that we should protect against those negatives if we > expect anyone to return space to the IANA. If we do not expect anyone > to return space - then we don't need a policy for IANA to hand out > that space at all. > >> If we can focus on the essential functions of IANA and stay out of all local >> policy issues, I think we might have a policy that can be passed globally. > > I hope we are close to such a policy. > ~Chris > >> -- >> =============================================== >> David Farmer Email:farmer at umn.edu >> Networking & Telecommunication Services >> Office of Information Technology >> University of Minnesota >> 2218 University Ave SE Phone: 612-626-0815 >> Minneapolis, MN 55414-3029 Cell: 612-812-9952 >> =============================================== >> > > -- > @ChrisGrundemann > weblog.chrisgrundemann.com > www.burningwiththebush.com > www.coisoc.org > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From marty at akamai.com Wed Sep 1 15:41:10 2010 From: marty at akamai.com (Hannigan, Martin) Date: Wed, 1 Sep 2010 15:41:10 -0400 Subject: [arin-ppml] Policy Proposal 2010-10 - Global Policy for IPv4 Allocations by the IANA Post Exhaustion In-Reply-To: <8AF80058-D90C-42AD-9443-963C7DF085E5@delong.com> Message-ID: On 9/1/10 3:22 PM, "Owen DeLong" wrote: > Chris, > > Consider the following two possibilities: > > 1. We put forth a policy which can pass in the APNIC region which allows IANA > to allocate returned space. > > 2. We don't get a global policy and the ITU uses that fact as an example of > why the RIR system cannot be trusted with such a vital resource. Doesn't the discrepancy in transfer policy already do that? > I don't like APNICs transfer policy any more than you do, but I think there is > more at stake not having a global policy than the concern about what happens > to a few final breadcrumbs of IPv4 or any particular RIR getting more than > their share of those crumbs. I think that we get the message with regards to the transfer section and we already identified that the problem with the allocation method was a mechanical problem and an suggested update is pending. Best, -M< From farmer at umn.edu Wed Sep 1 18:44:48 2010 From: farmer at umn.edu (David Farmer) Date: Wed, 01 Sep 2010 17:44:48 -0500 Subject: [arin-ppml] Policy Proposal 2010-10 - Global Policy for IPv4 Allocations by the IANA Post Exhaustion In-Reply-To: References: Message-ID: <4C7ED760.6050006@umn.edu> On 9/1/10 14:41 CDT, Hannigan, Martin wrote: > > On 9/1/10 3:22 PM, "Owen DeLong" wrote: > >> Chris, >> >> Consider the following two possibilities: >> >> 1. We put forth a policy which can pass in the APNIC region which allows IANA >> to allocate returned space. >> >> 2. We don't get a global policy and the ITU uses that fact as an example of >> why the RIR system cannot be trusted with such a vital resource. > > Doesn't the discrepancy in transfer policy already do that? Possibly, but that is a smaller and harder string to pull on, hard choices had to be made and we made them. All of the regions didn't come to exactly the same conclusions, but there is more the same then there is different. Yes, there is an important difference, but I believe that is way we have multiple regions. Because there are sometime differences, and multiple regions with distinct local policies allow for that, this is a strength more than a weakness. However, right now regarding a post run-out IANA allocation policy, we haven't made those hard choices. So, it is at least theoretically possible, resources could be stranded at IANA. The difference is pointing out inaction, when it is relatively easy to argue that action is necessary, verses arguing that the wrong choices were made. >> I don't like APNICs transfer policy any more than you do, but I think there is >> more at stake not having a global policy than the concern about what happens >> to a few final breadcrumbs of IPv4 or any particular RIR getting more than >> their share of those crumbs. > > I think that we get the message with regards to the transfer section and we > already identified that the problem with the allocation method was a > mechanical problem and an suggested update is pending. Thanks, and I eagerly await the update. By the way, I do appreciate the work you put into this, and do like the way you parsed the transfer issue. Personally, I really like the solution you can up with, and I think it is good policy. However, I also recognize that good policy is in the eye of the beholder, and those beholding this policy at the APNIC meeting didn't agree. > Best, > > -M< -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From owen at delong.com Wed Sep 1 20:31:12 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 2 Sep 2010 10:01:12 +0930 Subject: [arin-ppml] Policy Proposal 2010-10 - Global Policy for IPv4 Allocations by the IANA Post Exhaustion In-Reply-To: References: Message-ID: Sent from my iPad On Sep 2, 2010, at 5:11 AM, "Hannigan, Martin" wrote: > > > > On 9/1/10 3:22 PM, "Owen DeLong" wrote: > >> Chris, >> >> Consider the following two possibilities: >> >> 1. We put forth a policy which can pass in the APNIC region which allows IANA >> to allocate returned space. >> >> 2. We don't get a global policy and the ITU uses that fact as an example of >> why the RIR system cannot be trusted with such a vital resource. > > Doesn't the discrepancy in transfer policy already do that? > Not in my opinion. While I agree that the APNIC transfer policy is irresponsible at best, we will not improve upon that situation by failing to pass a policy which allows iana to distribute any fragments it collects. I think the better method of preventing APNIC from claiming blocks under that policy is simply not to pass return policies in the other region and if necessary work out individual region to region transfers. Letting this block a global policy for redistribution makes us look bad. Passing one is largely a no-op without implementing language at each RIR. > >> I don't like APNICs transfer policy any more than you do, but I think there is >> more at stake not having a global policy than the concern about what happens >> to a few final breadcrumbs of IPv4 or any particular RIR getting more than >> their share of those crumbs. > > > I think that we get the message with regards to the transfer section and we > already identified that the problem with the allocation method was a > mechanical problem and an suggested update is pending. > I would like to strongly encourage you to consider the language that came out of the discussion at APNIC. It is simple, safe, and likely to pass in each region. I think passing language this go-around is very important as iana exhaustion will already predate implementation in the best cases. Owen > Best, > > -M< From owen at delong.com Tue Sep 7 15:44:33 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 7 Sep 2010 12:44:33 -0700 Subject: [arin-ppml] Revised version of 2010-13 Message-ID: <49276D0A-8A86-40FF-A9FC-1CFD47F8AAFE@delong.com> Based on community input, draft policy 2010-13 has been updated to version 1.35. A summary of the changes: 1. Changed from surgical modification of 4.10 to outright full text replacement (improved clarity and a cleaner approach to the needed changes). 2. Added a reservation system allowing organizations to apply up front for up to 24 months of anticipated need from this pool, but, handing the space out only on a quarterly basis with strict obligations for proper usage of existing space prior to receiving each allotment. 3. Retuned sizing of certain categories of request. 4. Multiple cases of wordsmithing and reference cleanup. 5. Added case (e) to handle CDNs which need addresses for SSL terminators with strict limits on the amount of space available and stringent requirements on the number of hosts that must be dual-stacked. Here is the current revision of the policy: Draft Policy 2010-13: Permitted Uses of Space Reserved under NRPM 4.10 Proposal Originator: Owen DeLong Proposal Version: 1.35 Date: 5 September 2010 Proposal type: modify Policy term: permanent Policy statement: Rename section 4.10: "Dedicated IPv4 pool to facilitate IPv6 Deployment" Replace the text of section 4.10 in it's entirety with: 4.10 When ARIN receives its last /8 IPv4 allocation from IANA, that /8 will form a dedicated pool to facilitate IPv6 Deployment. Allocations and assignments from this block must be justified by immediate IPv6 deployment requirements. Examples of such needs include: IPv4 addresses for key dual stack DNS servers, and NAT-PT or NAT464 translators. ARIN staff will use their discretion when evaluating justifications. Following IANA depletion, all IPv4 address space returned directly to ARIN except space to be reissued under an 8.3 directed transfer will be added to this pool. 4.10.1 Reservation All space assigned or allocated under this policy will be reserved in advance for a maximum period of 24 months, requests for shorter reservations will be accepted. The total reservation size will be rounded up to a CIDR bit boundary. Each organization's reserved IPv4 space will be divided into one portion per quarter. If a shorter reservation is requested such that a quarterly allotment does not match a CIDR boundary, then each quarter's allotment except the last quarter shall be increased as needed to align on a CIDR bit boundary. The final quarter will receive only the space remaining in the full reservation. An org may request one reservation under each provision listed in section 4.10.4. 4.10.2 Addressing Plan Any organization wishing to recieve IPv4 addresses through this policy must submit a comprehensive plan detailing: (a) Their addressing needs over the entire reservation period and (b) Methods of meeting all requisite requirements (requirments are explained in section 4.10.4.) over the entire reservation period. A complete addressing plan must be submitted for each request made. If the submitted plan is accepted by ARIN staff as being complient with this policy, a reservation will be made and the first portion of the organization's reservation will be released. 4.10.3 Quarterly Obligations Once a reservation has been made by ARIN, the organization holding that reservation may request one additional portion of their reserved block each quarter until their reservation is exhausted or revoked. In order to recieve each additional portion, the organization must submit proof that: (a) The most recent 4.10 allocation/assignment is at least 80% utilized. (b) All utilization is permitted under the provision of section 4.10.4. which it was initially requested. (c) All prior 4.10 allocation/assignments are at least 90% utilized. For purposes of this computation, space received under each provision shall be considered separately if an organization has received resources through multiple provisions. Organizations must meet all obligations as above each quarter. An organization that fails only on utilization do to unanticipated address conservation shall not be penalized, but, such organization shall not receive an additional quarterly allotment until all obligations are met. An organization which does not receive a quarterly allotment for four consecutive quarters shall have their total reservation reduced by 2 quarterly allotments. If an organization does not meet all obligations in any given quarter, that organization shall not recieve a portion of their reserved block and their reserved block will be reduced by an amount equal to one portion. If an organization does not meet all obligations for three consecutive quarters, that organization forfeits the remainder of their reserved block. If an organization is using space received under 4.10 in a manner contrary to 4.10 et seq. that organization may have their entire allocation or assignment revoked. All 4.10. space forfeited, revoked or otherwise reclaimed shall be returned to the ARIN transition pool and shall be exempt from any requirement to return space to the IANA. 4.10.4 Specific types of transitional uses have specific requirements: (a) An ISP/LIR may request a block no smaller than a /25 nor larger than a /19 per quarter to be used to provide single IPv4 /32s to their customers which could justify a /28 or more of IPv4 under ARIN policies in effect at the time of IANA depletion. 1. No customer site may receive more than a single IPv4 /32 under this provision. 2. The customer must not have any other IPv4 allocations or assignments from the provider at the time of this assignment. 3. The customer must not have any direct assignments from ARIN at the time of this assignment. 4. The customer must not have more than a single IPv4 /32 from any other provider at the time of this assignment. 5. The customer must have IPv6 addresses with IPv6 connectivity to the ISP/LIR (must be dual-stacked). 6. The ISP/LIR must demonstrate that it already provides IPv6 addressing and connectivity to at least one existing customer for each /32 requested, up to 90% of their total customer base. 7. No organization shall receive more than a total of a /14 or equivalent under this section. (b) An ISP/LIR or End user organization may request a block no smaller than a /29 and no larger than a /23 per quarter to provide single IPv4 /32s to each physical server used to provide Internet reachable content. 1. Space issued under this provision is an assignment, not an allocation. An LIR may not distribute this space to their customers. 2. No server may recieve more than a single IPv4 /32 under this provision. 3. The server must have IPv6 addresses with IPv6 connectivity (must be dual-stacked). 4. The recieving organization must demonstrate that it already provides IPv6 addressing and connectivity to at least one existing server in addition to the server for which each /32 is requested, up to 100% of their total server base. (organizations which can show 100% dual stack are exempt from this requirement). 5. The recieving organization must enable all of their content on the following schedule: 25% of content IPv6 reachable within six months of receiving their first addresses under this policy 50% of content IPv6 reachable within one year of receiving their first addresses under this policy 75% of content IPv6 reachable within 18 months of receiving their first addresses under this policy 90% of content IPv6 reachable within 24 months of receiving their first addresses under this policy 6. No organization shall receive more than a total of a /16 or equivalent under this section. (c) An ISP/LIR or End user organization may request a block no smaller than a /29 and no larger than a /25 per quarter for purposes relevant to their ability to deploy IPv6. 1. Space issued under this provision is an assignment, not an allocation. An LIR may not distribute this space to their customers. 2. Space issued under this provision must be used to provide the required public IPv4 address(es) for transitional technologies operated by the recipient organization. Specific examples of permitted uses are: a. Large scale or "Carrier Grade" NAT b. NAT-PT c. DS-LITE/B4/AFTeR d. DNS64 or other transitional DNS enablers e. For other technologies of similar purpose and scope. 3. A /10 from the final /8 shall be reserved for issuance under this provision. In no case shall any addresses from this /10 be issued for any purpose outside of 4.10.4(c). (d) Applications which would qualify for IPv4 under section 4.4 of the NRPM (critical infrastructure) may qualify for IPv4 space under this policy if they meet the following criteria: 1. The critical infrastructure to be numbered must also have IPv6 addresses and must provide all services provided on IPv4 over IPv6 on the same time table. 2. Assignments under this provision shall be the smallest technically feasible size for the critical infrastructure in question. 3. The total space assigned under this provision shall not exceed the equivalent of a /14. (e) A content distribution network providing SSL terminations for SSL application or content acceleration may receive space under the following conditions: 1. No organization shall receive more than an aggregate /20 under this provision. 2. For each /32 issued under this provision, there must be at least 8 unique SSL named terminations converted to dual stack. (A unique named termination is one in which the certificate DistinguishedName and/or SubjectAltName is unique as well as the IP address terminating the connection). An organization which can show that they have dual stacked 100% of their SSL terminations shall be exempted from this requirement. 3. The total space issued under this provision shall not exceed an aggregate /11 or equivalent. End Owen From marty at akamai.com Tue Sep 7 16:04:55 2010 From: marty at akamai.com (Hannigan, Martin) Date: Tue, 7 Sep 2010 16:04:55 -0400 Subject: [arin-ppml] Revised version of 2010-13 In-Reply-To: <49276D0A-8A86-40FF-A9FC-1CFD47F8AAFE@delong.com> Message-ID: Owen, While this is making progress, and from what I can tell, this proposal continues to require a *substantial* amount of work in order to gain consensus. Best, -M< On 9/7/10 3:44 PM, "Owen DeLong" wrote: > Based on community input, draft policy 2010-13 has been updated to version > 1.35. > > A summary of the changes: > > 1. Changed from surgical modification of 4.10 to outright full text > replacement (improved clarity > and a cleaner approach to the needed changes). > > 2. Added a reservation system allowing organizations to apply up front > for up to 24 months > of anticipated need from this pool, but, handing the space out only on > a quarterly basis with > strict obligations for proper usage of existing space prior to > receiving each allotment. > > 3. Retuned sizing of certain categories of request. > > 4. Multiple cases of wordsmithing and reference cleanup. > > 5. Added case (e) to handle CDNs which need addresses for SSL terminators > with strict > limits on the amount of space available and stringent requirements on > the number of > hosts that must be dual-stacked. > > Here is the current revision of the policy: > > Draft Policy 2010-13: Permitted Uses of Space Reserved under NRPM 4.10 > Proposal Originator: Owen DeLong > Proposal Version: 1.35 > Date: 5 September 2010 > Proposal type: modify > Policy term: permanent > Policy statement: > > Rename section 4.10: "Dedicated IPv4 pool to facilitate IPv6 Deployment" > > Replace the text of section 4.10 in it's entirety with: > > 4.10 When ARIN receives its last /8 IPv4 allocation from IANA, that /8 will > form a > dedicated pool to facilitate IPv6 Deployment. Allocations and > assignments > from this block must be justified by immediate IPv6 deployment > requirements. > > Examples of such needs include: IPv4 addresses for key dual > stack DNS > servers, and NAT-PT or NAT464 translators. ARIN staff will use > their discretion > when evaluating justifications. Following IANA depletion, all > IPv4 address > space returned directly to ARIN except space to be reissued > under an 8.3 > directed transfer will be added to this pool. > > 4.10.1 Reservation > > All space assigned or allocated under this policy will be > reserved in advance > for a maximum period of 24 months, requests for shorter > reservations will be > accepted. The total reservation size will be rounded up to a > CIDR bit boundary. > > Each organization's reserved IPv4 space will be divided into > one > portion per quarter. If a shorter reservation is requested > such that a quarterly > allotment does not match a CIDR boundary, then each quarter's > allotment > except the last quarter shall be increased as needed to align > on a CIDR > bit boundary. The final quarter will receive only the space > remaining in the > full reservation. > > An org may request one reservation under each provision listed > in section > 4.10.4. > > 4.10.2 Addressing Plan > > Any organization wishing to recieve IPv4 addresses through > this policy must > submit a comprehensive plan detailing: > (a) Their addressing needs over the entire reservation > period and > (b) Methods of meeting all requisite requirements > (requirments are > explained in section 4.10.4.) over the entire > reservation period. > > A complete addressing plan must be submitted for each request > made. If the > submitted plan is accepted by ARIN staff as being complient > with this policy, a > reservation will be made and the first portion of the > organization's reservation > will be released. > > 4.10.3 Quarterly Obligations > > Once a reservation has been made by ARIN, the organization > holding that > reservation may request one additional portion of their > reserved block each > quarter until their reservation is exhausted or revoked. > > In order to recieve each additional portion, the organization > must submit proof > that: > (a) The most recent 4.10 allocation/assignment is at > least 80% utilized. > (b) All utilization is permitted under the provision > of section 4.10.4. which > it was initially requested. > (c) All prior 4.10 allocation/assignments are at least > 90% utilized. > > For purposes of this computation, space received under each > provision shall > be considered separately if an organization has received > resources through > multiple provisions. > > Organizations must meet all obligations as above each quarter. > An organization > that fails only on utilization do to unanticipated address > conservation shall not > be penalized, but, such organization shall not receive an > additional quarterly > allotment until all obligations are met. An organization which > does not receive > a quarterly allotment for four consecutive quarters shall have > their total > reservation reduced by 2 quarterly allotments. > > If an organization does not meet all obligations in any given > quarter, that > organization shall not recieve a portion of their reserved > block and their > reserved block will be reduced by an amount equal to one > portion. > > If an organization does not meet all obligations for three > consecutive quarters, > that organization forfeits the remainder of their reserved > block. > > If an organization is using space received under 4.10 in a > manner contrary to > 4.10 et seq. that organization may have their entire > allocation or assignment > revoked. > > All 4.10. space forfeited, revoked or otherwise reclaimed > shall be returned to > the ARIN transition pool and shall be exempt from any > requirement to return > space to the IANA. > > 4.10.4 Specific types of transitional uses have specific > requirements: > > (a) An ISP/LIR may request a block no smaller than a /25 > nor larger than a > /19 per quarter to be used to provide single IPv4 /32s > to their customers > which could justify a /28 or more of IPv4 under ARIN > policies in effect at > the time of IANA depletion. > 1. No customer site may receive more than a > single IPv4 /32 under this > provision. > 2. The customer must not have any other IPv4 > allocations or assignments > from the provider at the time of this > assignment. > 3. The customer must not have any direct > assignments from ARIN at the > time of this assignment. > 4. The customer must not have more than a single > IPv4 /32 from any > other provider at the time of this assignment. > 5. The customer must have IPv6 addresses with > IPv6 connectivity to > the ISP/LIR (must be dual-stacked). > 6. The ISP/LIR must demonstrate that it already > provides IPv6 > addressing and connectivity to at least one > existing customer > for each /32 requested, up to 90% of their > total customer base. > 7. No organization shall receive more than a > total of a /14 or > equivalent under this section. > > (b) An ISP/LIR or End user organization may request a > block no smaller > than a /29 and no larger than a /23 per quarter to > provide single > IPv4 /32s to each physical server used to provide > Internet reachable > content. > 1. Space issued under this provision is an > assignment, not an > allocation. An LIR may not distribute this > space to their customers. > 2. No server may recieve more than a single IPv4 > /32 under this > provision. > 3. The server must have IPv6 addresses with IPv6 > connectivity (must > be dual-stacked). > 4. The recieving organization must demonstrate > that it already > provides IPv6 addressing and connectivity to > at least one > existing server in addition to the server for > which each > /32 is requested, up to 100% of their total > server base. > (organizations which can show 100% dual stack > are exempt > from this requirement). > 5. The recieving organization must enable all of > their content > on the following schedule: > 25% of content IPv6 reachable within > six months of receiving > their first addresses under > this policy > 50% of content IPv6 reachable within > one year of receiving > their first addresses under > this policy > 75% of content IPv6 reachable within > 18 months of receiving > their first addresses under > this policy > 90% of content IPv6 reachable within > 24 months of receiving > their first addresses under > this policy > 6. No organization shall receive more than a > total of a /16 or > equivalent under this section. > > (c) An ISP/LIR or End user organization may request a > block no smaller > than a /29 and no larger than a /25 per quarter for > purposes > relevant to their ability to deploy IPv6. > 1. Space issued under this provision is an > assignment, not an > allocation. An LIR may not distribute this > space to their customers. > 2. Space issued under this provision must be used > to provide the > required public IPv4 address(es) for > transitional technologies > operated by the recipient organization. > > Specific examples of permitted uses are: > a. Large scale or "Carrier Grade" NAT > b. NAT-PT > c. DS-LITE/B4/AFTeR > d. DNS64 or other transitional DNS enablers > e. For other technologies of similar purpose > and scope. > > 3. A /10 from the final /8 shall be reserved for > issuance under this > provision. In no case shall any addresses from > this /10 be issued > for any purpose outside of 4.10.4(c). > > (d) Applications which would qualify for IPv4 under > section 4.4 of > the NRPM (critical infrastructure) may qualify for > IPv4 space > under this policy if they meet the following criteria: > 1. The critical infrastructure to be numbered > must also have > IPv6 addresses and must provide all services > provided on > IPv4 over IPv6 on the same time table. > 2. Assignments under this provision shall be the > smallest > technically feasible size for the critical > infrastructure in > question. > 3. The total space assigned under this provision > shall not > exceed the equivalent of a /14. > > (e) A content distribution network providing SSL > terminations for > SSL application or content acceleration may receive > space > under the following conditions: > 1. No organization shall receive more than an > aggregate /20 > under this provision. > 2. For each /32 issued under this provision, > there must be at > least 8 unique SSL named terminations > converted to dual > stack. (A unique named termination is one in > which the > certificate DistinguishedName and/or > SubjectAltName > is unique as well as the IP address > terminating the > connection). An organization which can show > that they > have dual stacked 100% of their SSL > terminations shall > be exempted from this requirement. > 3. The total space issued under this provision > shall not exceed > an aggregate /11 or equivalent. > > End > > Owen > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From michael.dillon at bt.com Thu Sep 9 06:16:09 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 9 Sep 2010 11:16:09 +0100 Subject: [arin-ppml] 2010-8: Rework of IPv6 assignment criteria In-Reply-To: <20100821170927.GA15061@panix.com> References: <4C6EF2BA.207@umn.edu> <20100821170927.GA15061@panix.com> Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6CD49@EMV01-UKBR.domain1.systemhost.net> > What is the definition of site? Any building/campus in the network? A site is a place that one would normally distinguish from another place. For an ISP, a whole college campus might be considered a site since they serve it with a pair of redundant fiber links, but for the college IT folks, each building might be considered a site, and in some cases, part of a building. For instance if two departments share a building, and there are two separate network links to that building, then it is reasonable to consider it as two sites. In the above scenario, the ISP would probably say to the college folks, "you are one site, here is your /48 assignment". The college folks would then say, "we already have our IPv6 architecture in place, and in fact we have 37 sites therefore we would like 37 /48 allocations". In this scenario, the right thing to do is to give the college the number of /48s that they need to cover the site architecture that they have deployed. That is because "SITE" can only be defined locally where there is enough info to see how to distinguish one place from another. A residential apartment building with 76 apartments would have just over 76 sites, since you need to allow for at least one if not more /48s to cover the building maintenance department. Each individual residence is a site. > For example, is every large (1501 stores or more) retail company in the > ARIN region entitled to a /32? Clearly they have more than 1501 sites because they also have warehouses and a head office site. The question is, do they have a network? Two identical retail chains could answer that question differently. One might say that they buy Internet access from two different ISPs and their IT department maintains an IPSEC VPN connecting all the sites, therefore they just get /48s per site like any other ISP customer. But another retail chain might buy IP-MPLS connectivity from a large network operator and run their own IP network over this infrastructure using an ARIN PI block, and then peer with their network operator's ISP division over the big pipe into head office. A site can only be defined locally, and the most important thing is that there is some distinction between the location of one site and another. This distinction is what makes it into a "site". And the same physical collection of sites could receive addresses in more than one way. Either PI from ARIN or PA assignments from an ISP as above. Or they could even light up dark fiber and get an ARIN PA allocation as a network operator. It might be a bit of a stretch to see a retail chain as a network operator, although I am aware of at least one German/Polish chain that has a RIPE PA allocation like that. But it is less of a stretch to see a cinema chain operating their own network over dark fiber, and cinema is a retail sort of business. > They'd all meet requirement 6.5.8.1(c) > below; most or all would meet 6.5.8.1(a), so that gets them in the door > for an IPv6 assignmnet of some size. It's not a question of what requirements do they meet, it is a question of what are they doing. Are they operating a network? Is it a stable fixed size network (PI)? or a constantly growing network (PA)? Or do they just buy services from ISPs? > This isn't necessarily a problem -- IPv6 space isn't scarce the way > IPv4 is -- I'm just asking what you intended the definition of "site" > to be. That's exactly right. IPv6 space is not scarce, and if there is a clash between the fundamentals that I have descrivbed above, and ARIN policy, then it is highly likely that ARIN policy will adjust. There is a lot of change going on right now with networks and how people make use of them, and that will drive a shift in demand patterns for IPv6 once we get past the chaotic transition period. It's best to not shoehorn people's network designs into ARIN policy quirks, but instead keep the network architectures clean and simple and demand ARIN policy changes to fit that. --Michael Dillon From michael.dillon at bt.com Thu Sep 9 06:18:24 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 9 Sep 2010 11:18:24 +0100 Subject: [arin-ppml] 2010-8: Rework of IPv6 assignment criteria In-Reply-To: <0267B5481DCC474D8088BF4A25C7F1DF5516E41BB4@XCH-NW-05V.nw.nos.boeing.com> References: <4C6EF2BA.207@umn.edu> <0267B5481DCC474D8088BF4A25C7F1DF5516E41BB4@XCH-NW-05V.nw.nos.boeing.com> Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6CD4E@EMV01-UKBR.domain1.systemhost.net> > > c. By having a network consisting of a total of 1000 or more > > hosts, or; What is a "host"? A single factory could have over a thousand little sensor units with unique IPv4 addresses. Are those hosts? A single rented rack in an Equinox data center could have over 1000 XEN virtual servers with unique IPv4 addresses. Are those hosts? --Michael Dillon From owen at delong.com Thu Sep 9 07:07:14 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Sep 2010 04:07:14 -0700 Subject: [arin-ppml] 2010-8: Rework of IPv6 assignment criteria In-Reply-To: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6CD4E@EMV01-UKBR.domain1.systemhost.net> References: <4C6EF2BA.207@umn.edu> <0267B5481DCC474D8088BF4A25C7F1DF5516E41BB4@XCH-NW-05V.nw.nos.boeing.com> <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6CD4E@EMV01-UKBR.domain1.systemhost.net> Message-ID: <74CF4584-61DB-4310-AB8F-26F9504086DF@delong.com> On Sep 9, 2010, at 3:18 AM, wrote: >>> c. By having a network consisting of a total of 1000 or more >>> hosts, or; > > What is a "host"? > A single factory could have over a thousand little sensor units with > unique IPv4 addresses. Are those hosts? > > A single rented rack in an Equinox data center could have over 1000 > XEN virtual servers with unique IPv4 addresses. Are those hosts? > Yes. Owen From farmer at umn.edu Thu Sep 9 08:39:47 2010 From: farmer at umn.edu (David Farmer) Date: Thu, 09 Sep 2010 07:39:47 -0500 Subject: [arin-ppml] 2010-8: Rework of IPv6 assignment criteria In-Reply-To: <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6CD4E@EMV01-UKBR.domain1.systemhost.net> References: <4C6EF2BA.207@umn.edu> <0267B5481DCC474D8088BF4A25C7F1DF5516E41BB4@XCH-NW-05V.nw.nos.boeing.com> <0F29D1BA57992E4CAB5AD2C9AE7B42391CE6CD4E@EMV01-UKBR.domain1.systemhost.net> Message-ID: <4C88D593.7000709@umn.edu> On 9/9/10 05:18 CDT, michael.dillon at bt.com wrote: >>> c. By having a network consisting of a total of 1000 or more >>> hosts, or; > > What is a "host"? > A single factory could have over a thousand little sensor units with > unique IPv4 addresses. Are those hosts? > > A single rented rack in an Equinox data center could have over 1000 > XEN virtual servers with unique IPv4 addresses. Are those hosts? > > --Michael Dillon Yes, but we have that problem now, it is not a new one. My intent for including this clause is to eliminate potential inequities, right now if you have 1000 hosts you can justify getting IPv4 address space, without being multihomed. Therefore, you can justify getting IPv6 space. Because anyone who can get IPv4 space must be able to get IPv6 space to enable transition. What I am trying to ensure is that the moment after IPv4 run-out occurs that someone who qualified for both IPv4 and IPv6, still qualifies for IPv6 even though there is no longer any IPv4 space left. Long-term term I would prefer this clause were eliminated or that it wasn't necessary. However, I believe this cause is necessary in the short-term to eliminate any discontinuity at the moment of IPv4 run-out. My intent in having it as a separate clause, is to make it easy to eliminate at the proper time, like a year or two after IPv4 run-out. I open to suggestions for a better way to achieve this goal, but I think it is important that the moment of IPv4 run-out doesn't accidentally change who is eligible for IPv6 address space. I believe this is consistent with the current policy language and necessary during IPv4's run-out phase, -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From ljorgenson at inetco.com Thu Sep 9 13:50:35 2010 From: ljorgenson at inetco.com (Loki Jorgenson) Date: Thu, 9 Sep 2010 10:50:35 -0700 Subject: [arin-ppml] What is a "host"? In-Reply-To: References: Message-ID: <4C891E6B.3020508@inetco.com> Pardon for butting in mid-conversation - but this particular bit of semantics has aggravated us before and so it is topical. "Host" tends to be rather over-loaded semantically and in general has connotation that ties it to a physical or virtual machine. It will likely be problematic if you don't get your key terms defined, particularly as it appears in policy and will need to be interpreted. "Host" doesn't map well to IP addresses except in the simplest case. And in an increasingly sensor network, mobile, and cloud-based world, this won't fit well. Alternately, I could suggest something like "node" (or "network node") and subsequently "node IP end-point" or "IP node" or "IP end-point". Here "end" relates to a point-to-point IP connection, not an end-to-end network path. Sensors (and anything else with an address) then are simply IP nodes (or comprise at least one IP node). A host then may have a plurality of IP nodes (either physical or virtual). NOTE: I haven't looked closely at the document - I'm still catching up having just joined the list. On 10-09-09 9:00 AM, arin-ppml-request at arin.net wrote: >>>> c. By having a network consisting of a total of 1000 or more >>>> hosts, or; >> What is a "host"? >> A single factory could have over a thousand little sensor units with >> unique IPv4 addresses. Are those hosts? >> >> A single rented rack in an Equinox data center could have over 1000 >> XEN virtual servers with unique IPv4 addresses. Are those hosts? >> > Yes. > > Owen -- Loki Jorgenson ljorgenson at inetco.com INETCO Systems (604) 451-1567 x131 From tedm at ipinc.net Thu Sep 9 14:29:57 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 09 Sep 2010 11:29:57 -0700 Subject: [arin-ppml] What is a "host"? In-Reply-To: <4C891E6B.3020508@inetco.com> References: <4C891E6B.3020508@inetco.com> Message-ID: <4C8927A5.1080202@ipinc.net> In my opinion anything on a network that UNIQUELY receives or sends data is a "host" even if it requires multiple IP addresses to do it. If a sensor on a refrigerator does this then it's a host, even if it's behind a firewall. If the sensor only sends data to a master control computer in the refrigerator then it still is a host - it's just only a host in the context of the little tiny network within the refrigerator. If a webserver has virtual servers on it then those servers are hosts, as is the webserver that those servers are contained in. If a webserver merely has some virtual websites then those websites are not hosts, because if you access them your still talking to the same master control operating system. I realize this sounds odd but look at it this way. I could setup a server with a virtual server in the server. I can then launch an attack on the server -from- the virtual server and compromise the server, even though the virtual was not compromised. A router that spends most of it's time forwarding packets is also a host because you can telnet into it. So is a smart ethernet bridge, or a managed switch. A dumb switch is NOT a host. As for so called "cloud" computing, a "cloud" is a host, as are the elements in a cloud - if those can send and receive unique data. I do not believe that the term host is problematic or ill defined. I DO believe that there are a lot of people running around out there who have axes to grind who would like to replace "host" with something else. I also believe there are people who have a vested interest in some semantic wordgame with the term to try and scam resources that they aren't entitled to. The term "host" came out of the Unix world and Microsoft has been involved in a decades long campaign to wipe out usage of any term that carries a Unix connotation. That is why they invented terms like "Domain Controller" when they meant NetBIOS Name Server, and terms like Active Directory when they meant Network Information Service (AKA Yellow Pages) They want to make the unwary think that they have created something new and original rather than ripping-off older ideas that Novell had developed, who in turn ripped them off from even older ideas that Sun had developed. Apple is famous for doing this as well. We also have Google and others who have begun to see the marketing advantages of these kinds of semantic wordgames. For further reading I would encourage you to read the book "1984" by George Orwell. It contains an excellent description of how to control something by redefining words. You can also look up the numerous publications of the worlds major religions which do the same thing. Ted On 9/9/2010 10:50 AM, Loki Jorgenson wrote: > Pardon for butting in mid-conversation - but this particular bit of > semantics has aggravated us before and so it is topical. > > "Host" tends to be rather over-loaded semantically and in general has > connotation that ties it to a physical or virtual machine. It will > likely be problematic if you don't get your key terms defined, > particularly as it appears in policy and will need to be interpreted. > "Host" doesn't map well to IP addresses except in the simplest case. And > in an increasingly sensor network, mobile, and cloud-based world, this > won't fit well. > > Alternately, I could suggest something like "node" (or "network node") > and subsequently "node IP end-point" or "IP node" or "IP end-point". > Here "end" relates to a point-to-point IP connection, not an end-to-end > network path. Sensors (and anything else with an address) then are > simply IP nodes (or comprise at least one IP node). A host then may have > a plurality of IP nodes (either physical or virtual). > > NOTE: I haven't looked closely at the document - I'm still catching up > having just joined the list. > > On 10-09-09 9:00 AM, arin-ppml-request at arin.net wrote: >>>>> c. By having a network consisting of a total of 1000 or more >>>>> hosts, or; >>> What is a "host"? >>> A single factory could have over a thousand little sensor units with >>> unique IPv4 addresses. Are those hosts? >>> >>> A single rented rack in an Equinox data center could have over 1000 >>> XEN virtual servers with unique IPv4 addresses. Are those hosts? >>> >> Yes. >> >> Owen > From owen at delong.com Thu Sep 9 14:37:38 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Sep 2010 11:37:38 -0700 Subject: [arin-ppml] What is a "host"? In-Reply-To: <4C891E6B.3020508@inetco.com> References: <4C891E6B.3020508@inetco.com> Message-ID: <48FF801D-3E20-4621-8684-C78F15A99B61@delong.com> On Sep 9, 2010, at 10:50 AM, Loki Jorgenson wrote: > Pardon for butting in mid-conversation - but this particular bit of semantics has aggravated us before and so it is topical. > > "Host" tends to be rather over-loaded semantically and in general has connotation that ties it to a physical or virtual machine. It will likely be problematic if you don't get your key terms defined, particularly as it appears in policy and will need to be interpreted. "Host" doesn't map well to IP addresses except in the simplest case. And in an increasingly sensor network, mobile, and cloud-based world, this won't fit well. > Host maps particularly well in this context, actually. The term host, as I would intend it in this policy would be to count each item which requires a link-local IPv6 address other than loopback interfaces as a host. Thus, 100 IP addresses on a single interface would be one host. 100 interfaces on a single machine would be 100 hosts. The interfaces of 100 virtuals running on a single machine would be 100 hosts. A sensor that has an IPv6 address would be a host. etc. > Alternately, I could suggest something like "node" (or "network node") and subsequently "node IP end-point" or "IP node" or "IP end-point". Here "end" relates to a point-to-point IP connection, not an end-to-end network path. Sensors (and anything else with an address) then are simply IP nodes (or comprise at least one IP node). A host then may have a plurality of IP nodes (either physical or virtual). > I would argue that the terms host and node are synonymous, at least for purposes of this discussion, and I don't see a meaningful difference in the terminology. Owen From bill at herrin.us Thu Sep 9 15:23:25 2010 From: bill at herrin.us (William Herrin) Date: Thu, 9 Sep 2010 15:23:25 -0400 Subject: [arin-ppml] What is a "host"? In-Reply-To: <4C891E6B.3020508@inetco.com> References: <4C891E6B.3020508@inetco.com> Message-ID: On Thu, Sep 9, 2010 at 1:50 PM, Loki Jorgenson wrote: > "Host" tends to be rather over-loaded semantically and in general has > connotation that ties it to a physical or virtual machine. ?It will likely > be problematic if you don't get your key terms defined, particularly as it > appears in policy and will need to be interpreted. ?"Host" doesn't map well > to IP addresses except in the simplest case. ?And in an increasingly sensor > network, mobile, and cloud-based world, this won't fit well. Classically (read: not IPv6), a host is any device that speaks TCP/IP. Node is used interchangeably while other terms are used to specify specific types of host, such as a router. Officially in IPv6: http://www.ietf.org/rfc/rfc4294.txt Description of an IPv6 Node - a device that implements IPv6. Description of an IPv6 router - a node that forwards IPv6 packets not explicitly addressed to itself. Description of an IPv6 Host - any node that is not a router. Obligatory limerick: A host is a host, >From coast to coast And nobody talks to a host that's close, Unless the host that isn't close Is busy, hung, or dead. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From info at arin.net Thu Sep 9 16:12:59 2010 From: info at arin.net (ARIN) Date: Thu, 09 Sep 2010 16:12:59 -0400 Subject: [arin-ppml] =?windows-1252?q?NRPM_2010=2E3_=96_New_Policies_Imple?= =?windows-1252?q?mented?= Message-ID: <4C893FCB.90600@arin.net> A new version of the ARIN Number Resource Policy Manual (NRPM) has been published to the ARIN website. NRPM version 2010.3 is effective 9 September 2010 and supersedes the previous version. NRPM version 2010.3 contains the implementation of the following policies: 2010-2: /24 End User Minimum Assignment Unit 2010-4: Rework of IPv6 allocation criteria 2010-6: Simplified M&A transfer policy The NRPM is available at: https://www.arin.net/policy/nrpm.html The Change Log is available at: https://www.arin.net/policy/nrpm_changelog.html Draft policies and proposals are available at: https://www.arin.net/policy/proposals/ The PDP is available at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From ljorgenson at inetco.com Fri Sep 10 12:57:52 2010 From: ljorgenson at inetco.com (Loki Jorgenson) Date: Fri, 10 Sep 2010 09:57:52 -0700 Subject: [arin-ppml] what is a host? In-Reply-To: References: Message-ID: <4C8A6390.3070405@inetco.com> Thanks for your responses, Ted and Owen and Bill - great intro for me to the list. The suggestions aside, my main point was that the terms used should be unambiguous so that there can be no "scamming of resources" via "semantic word games". The IETF usage (i.e. RFC4294) as standard would be a fine example. Not sure yet what the traditions are in this forum with regard to implicit or explicit adoption of references. On 10-09-10 9:00 AM, arin-ppml-request at arin.net wrote: > > Message: 2 > Date: Thu, 09 Sep 2010 11:29:57 -0700 > From: Ted Mittelstaedt > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] What is a "host"? > Message-ID:<4C8927A5.1080202 at ipinc.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > In my opinion anything on a network that UNIQUELY receives or > sends data is a "host" even if it requires multiple IP addresses > to do it. > > If a sensor on a refrigerator does this then it's a host, even if > it's behind a firewall. If the sensor only sends data to a master > control computer in the refrigerator then it still is a host - it's just > only a host in the context of the little tiny network within the > refrigerator. > > If a webserver has virtual servers on it then those servers are hosts, > as is the webserver that those servers are contained in. If a webserver > merely has some virtual websites then those websites are not hosts, > because if you access them your still talking to the same master control > operating system. I realize this sounds odd but look at it this way. I > could setup a server with a virtual server in the server. I can then > launch an attack on the server -from- the virtual server and compromise > the server, even though the virtual was not compromised. > > A router that spends most of it's time forwarding packets is also > a host because you can telnet into it. So is a smart ethernet bridge, > or a managed switch. A dumb switch is NOT a host. > > As for so called "cloud" computing, a "cloud" is a host, as are the > elements in a cloud - if those can send and receive unique data. > > I do not believe that the term host is problematic or ill defined. I > DO believe that there are a lot of people running around out there > who have axes to grind who would like to replace "host" with something > else. I also believe there are people who have a vested interest in > some semantic wordgame with the term to try and scam resources that they > aren't entitled to. > > The term "host" came out of the Unix world and Microsoft has been > involved in a decades long campaign to wipe out usage of any term that > carries a Unix connotation. That is why they invented terms like > "Domain Controller" when they meant NetBIOS Name Server, and terms like > Active Directory when they meant Network Information Service (AKA Yellow > Pages) They want to make the unwary think that they have created > something new and original rather than ripping-off older ideas that > Novell had developed, who in turn ripped them off from even older > ideas that Sun had developed. Apple is famous for doing this as well. > > We also have Google and others who have begun to see the marketing > advantages of these kinds of semantic wordgames. > > For further reading I would encourage you to read the book "1984" > by George Orwell. It contains an excellent description of how to > control something by redefining words. You can also look up the > numerous publications of the worlds major religions which do the > same thing. > > Ted > > > On 9/9/2010 10:50 AM, Loki Jorgenson wrote: >> Pardon for butting in mid-conversation - but this particular bit of >> semantics has aggravated us before and so it is topical. >> >> "Host" tends to be rather over-loaded semantically and in general has >> connotation that ties it to a physical or virtual machine. It will >> likely be problematic if you don't get your key terms defined, >> particularly as it appears in policy and will need to be interpreted. >> "Host" doesn't map well to IP addresses except in the simplest case. And >> in an increasingly sensor network, mobile, and cloud-based world, this >> won't fit well. >> >> Alternately, I could suggest something like "node" (or "network node") >> and subsequently "node IP end-point" or "IP node" or "IP end-point". >> Here "end" relates to a point-to-point IP connection, not an end-to-end >> network path. Sensors (and anything else with an address) then are >> simply IP nodes (or comprise at least one IP node). A host then may have >> a plurality of IP nodes (either physical or virtual). >> >> NOTE: I haven't looked closely at the document - I'm still catching up >> having just joined the list. >> >> -- Loki Jorgenson ljorgenson at inetco.com INETCO Systems (604) 908-5833 From marty at akamai.com Mon Sep 13 19:36:07 2010 From: marty at akamai.com (Hannigan, Martin) Date: Mon, 13 Sep 2010 19:36:07 -0400 Subject: [arin-ppml] What is a "host"? In-Reply-To: Message-ID: On 9/9/10 3:23 PM, "William Herrin" wrote: > On Thu, Sep 9, 2010 at 1:50 PM, Loki Jorgenson wrote: >> "Host" tends to be rather over-loaded semantically and in general has >> connotation that ties it to a physical or virtual machine. ?It will likely >> be problematic if you don't get your key terms defined, particularly as it >> appears in policy and will need to be interpreted. ?"Host" doesn't map well >> to IP addresses except in the simplest case. ?And in an increasingly sensor >> network, mobile, and cloud-based world, this won't fit well. > > > Classically (read: not IPv6), a host is any device that speaks TCP/IP. > Node is used interchangeably while other terms are used to specify > specific types of host, such as a router. > > > Officially in IPv6: http://www.ietf.org/rfc/rfc4294.txt > > Description of an IPv6 Node > - a device that implements IPv6. > > Description of an IPv6 router > - a node that forwards IPv6 packets not explicitly addressed > to itself. > > Description of an IPv6 Host > - any node that is not a router. > +1 From marty at akamai.com Tue Sep 14 01:06:01 2010 From: marty at akamai.com (Hannigan, Martin) Date: Tue, 14 Sep 2010 01:06:01 -0400 Subject: [arin-ppml] Suggested updates to Draft Policy 2010-10 (Global Proposal) Message-ID: Hello PPML: A fair amount of feedback was received with regards to the Subject proposal. The original authors of the proposal discussed all of the feedback and additional suggestions are below: 1. Allocation method was unfair The intent was not for a single RIR to be able to be allocated all available address space in mass quantities. We do however want any available address space to be utilized if there is need. We've addressed what we would characterize as a mechanical issue. --new text Section 3. Address Allocations from the Reclamation Pool by the IANA Allocations from the Reclamation Pool may begin once the pool is declared active. Addresses in the Reclamation Pool must be allocated on a CIDR boundary. Allocations from the Reclamation Pool are subject to a minimum allocation unit equal to the minimum allocation unit of all RIRs and a maximum allocation unit of one /8. The Reclamation Pool will be divided on CIDR boundaries and distributed evenly to all eligible RIRs once each quarter. Any remainder not evenly divisible by the number of eligible RIRs based on a CIDR boundary equal to or larger than the minimum allocation unit will remain in the Reclamation Pool. Addresses that are left over will be held in the Reclamation Pool until additional IP addresses can be returned to rejoin addresses on CIDR boundaries to the Reclamation Pool or a minimum allocation unit is set to allow allocation from existing inventory. 2. Without excluding transition space, some RIR's would never be eligible We've defined a /10 credit to be applied for "all" pools of address space set-aside by any RIR that has them. --new text Section 4. RIR Eligibility for Receiving Allocations from the Reclamation Pool Upon the exhaustion of an RIR's free space pool and after receiving their final /8 from the IANA[3], an RIR will become eligible to request address space from the IANA Reclamation Pool when it publicly announces via its respective global announcements email list and by posting a notice on its website that it has exhausted its supply of IPv4 address space. Exhaustion is defined as an inventory of less than the equivalent of a single /8 and the inability to further assign address space to its customers in units equal to or shorter than the longest of any RIR's policy defined minimum allocation unit. Up to one /10 or equivalent of IPv4 address space specifically reserved for any special purpose by an RIR will not be counted against that RIR when determining eligibility unless that space was received from the IANA reclamation pool. Any RIR that is formed after the ICANN Board of Directors has ratified this policy is not eligible to utilize this policy to obtain IPv4 address space from the IANA. 3. Transfer Rights No plans to make suggestions that the AC modify transfer. 4. Additional comments One comment [Bill H.] seemed to adequately represent all who may believe that such a policy is not needed or required; 'No one in their right mind would return address space to an RIR considering how much it might be worth'. I'm aware of at least one entity that has signed up to return a /8 in the next month or two. Stay tuned. Best, -M< From farmer at umn.edu Tue Sep 14 03:52:58 2010 From: farmer at umn.edu (David Farmer) Date: Tue, 14 Sep 2010 02:52:58 -0500 Subject: [arin-ppml] 2010-8: Rework of IPv6 assignment criteria Message-ID: <4C8F29DA.8020003@umn.edu> Based on feedback and off-line discussion over the past few weeks I have made a number of updates to 2010-8; These include: - Changing from HD-Ratio to a 75% utilization threshold - Major rewrites of the initial assignment size and subsequent assignment size sections - Associated updates to the Rationale --------------- 1. Policy Proposal Name: Rework of IPv6 assignment criteria 2. Proposal Originator name: David Farmer email: farmer at umn.edu telephone: 612-812-9952 organization: University of Minnesota 3. Proposal Version: 6.0 4. Date: 9/14/2010 5. Proposal type: modify new, modify, or delete. 6. Policy term: Permanent temporary, permanent, or renewable. 7. Policy statement: Replace section 6.5.8 as follows; 6.5.8. Direct assignments from ARIN to end-user organizations 6.5.8.1 Initial Assignment Criteria Organizations may justify an initial assignment for addressing devices directly attached to their own network infrastructure, with an intent for the addresses to begin operational use within 12 months, by meeting one of the following criteria: a. Having a previously justified IPv4 end-user assignment from ARIN or one of its predecessor registries, or; b. Currently being IPv6 Multihomed or immediately becoming IPv6 Multihomed and using an assigned valid global AS number, or; c. By having a network consisting of a total of 1000 or more hosts, or; d. By providing a reasonable technical justification indicating why IPv6 addresses from an ISP or other LIR are unsuitable. Examples of justifications for why addresses from an ISP or other LIR may be unsuitable include, but are not limited to: ? An organization that operates infrastructure critical to life safety or the functioning of society can justify the need for an assignment based on the fact that renumbering would have a broader than expected impact than simply the number of hosts directly involved. These would include: hospitals, fire fighting, police, emergency response, power or energy distribution, water or waste treatment, traffic management and control, etc? ? Regardless of the number of hosts directly involved, an organization can justify the need for an assignment if renumbering would affect 1000 or more individuals either internal or external to the organization. ? An organization with a network not connected to the Internet can justify the need for an assignment by documenting a need for guaranteed uniqueness, beyond the statistical uniqueness provided by ULA (see RFC 4193). ? An organization with a network not connected to the Internet, such as a VPN overlay network, can justify the need for an assignment if they require authoritative delegation of reverse DNS. 6.5.8.2 Initial assignment size Organizations that meet at least one of the initial assignment criteria above are eligible to receive an initial assignment of /48. Requests for larger initial assignments, reasonably justified with supporting documentation, will be evaluated based on the number of sites in an organization?s network and the number of subnets needed to support any extra-large sites defined below. 6.5.8.2.1 /48 per site An organization may request up to a /48 for each site in its network, including any sites that will be operational within 12 months. Where a site is a discrete location that is part of an organization?s network. In the case of a multi-tenant building, each organization located at the site may separately justify a /48 for its network at the site. A campus with multiple buildings may be considered as one or multiple sites, based on the implementation of its network infrastructure. For a campus to be considered as multiple sites, reasonable technical documentation must be submitted describing how the network infrastructure is implemented in a manner equivalent to multiple sites. 6.5.8.2.2 Extra-large site In rare cases, an organization may request more than a /48 for an extra-large site which requires more than 16,384 /64 subnets. In such a case, a detailed subnet plan must be submitted for each extra-large site in an organization?s network. An extra-large site will receive the smallest prefix such that the total subnet utilization justified does not exceed 25%. Each extra-large site will be counted as an equivalent number of /48 sites. 6.5.8.2.3 Larger initial assignments Larger initial assignments will be determined based on the number of sites justified above, aligned on a nibble boundary using the following table: More than 1 but less than or equal to 12 sites justified, receives a /44 assignment; More than 12 but less than or equal to 192 /sites justified, receives a /40 assignment; More than 192 but less than or equal to 3,072 sites justified, receives a /36 assignment; More than 3,072 sites justified, receives a /32 assignment or larger. In cases where more than 3,072 sites are justified, an assignment of the smallest prefix, aligned on a nibble boundary, will be made such that the total utilization based on the number of sites justified above does not exceed 75%. 6.5.8.3 Subsequent assignments Requests for subsequent assignments with supporting documentation will be evaluated based on the same criteria as an initial assignment under 6.5.8.2 with the following modifications: a. A subsequent assignment is justified when the total utilization based on the number of sites justified exceeds 75% across all of an organization?s assignments. Except, if the organization received an assignment per section 6.11 IPv6 Multiple Discrete Networks, such assignments will be evaluated as if it were to a separate organization. Organizations may have multiple separate assignments that should be considered in total, due to previous subsequent assignments made per clause 6.5.8.3.c below, or through Mergers and Acquisitions in section 8.2. b. When possible subsequent assignments will result it the expansion of an existing assignment by one or more nibble boundaries as justified. c. If it is not possible to expand an existing assignment, or to expand it adequately to meet the justified need, then a separate new assignment will be made of a size as justified. 6.5.8.4 Consolidation and return of separate assignments Organizations with multiple separate assignments should consolidate into a single aggregate, if feasible. If an organization stops using one or more of its separate assignments, any unused assignments must be returned to ARIN. Rationale: This proposal provides a complete rework of the IPv6 end-user assignment criteria, removing the dependency on IPv4 policy, providing clear guidance in requesting larger initial assignments, and eliminating HD-Ratio as criteria for evaluating end-user assignments. The HD-Ratio is replaced with a simplified 75% utilization threshold based on nibble boundaries for end-user assignments. This threshold is somewhat more restrictive for larger assignments, while slightly less restrictive for the smaller /44 assignments, than the HD-Ratio. However, in both cases it is much easier for an end-user to understand the policy criteria that applies to them. The following general concepts are included: ? Previously justified IPv4 resources may be used to justify the need for IPv6 resources ? Internet multihoming is sufficient justification for an IPv6 end-user assignment in and of itself ? Networks with more than 1000 hosts have a justified need for IPv6 resources; as is the case in current policy, it is just more clearly stated without relying on a reference to, and the consequences of, IPv4 policy ? Other end-users must justify why an ISP or LIR assignment is not sufficient for their needs ? Organizations with multiple sites may receive a /48 for each site in their network ? A campus with multiple buildings may be considered as one or multiple sites, based on the implementation of its network infrastructure ? Reservations are no longer necessary as ARIN has committed to sparse assignment for IPv6 ? Providing sufficiently large initial assignments based on nibble boundaries along with sparse assignments will reduce route table growth caused solely by subsequent assignments The 25% subnet utilization for an extra-large site is proposed as the threshold for a larger prefix in order to allow an extra-large site enough room to create an organized subnet plan. Requiring denser usage would make it almost impossible for an extra-large site to maintain any kind of organized subnet plan. Furthermore, even at 25% utilization, more than 16,384 subnets are required to justify more than a /48 for a site. Few, if any, sites can actually meet or exceed this threshold. The ARIN Board of Trusties should consider incentives that provide additional motivation for end-users to consolidate into a single aggregate per section 6.5.8.4 of this policy. Timetable for implementation: Immediate -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From owen at delong.com Tue Sep 14 20:46:48 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Sep 2010 17:46:48 -0700 Subject: [arin-ppml] Updates to draft policy 2010-13 Message-ID: <9225625A-5D80-4A30-B091-32EADE00310B@delong.com> Based on additional community feedback, 2010-13 has again been revised. Here is an updated version: Here is the updated text: Draft Policy 2010-13: Permitted Uses of Space Reserved under NRPM 4.10 Proposal Originator: Owen DeLong Proposal Version: 1.38 Date: 5 September 2010 Proposal type: modify Policy term: permanent Policy statement: Rename section 4.10: "IPv4 Transition Pool Post IANA Regular Pool Depletion" Replace the text of section 4.10 in it's entirety with: 4.10 When ARIN receives its /8 IPv4 allocation from IANA under the global policy titled "Global Policy for the Allocation of the Remaining IPv4 Address Space" ratified by ICANN Board on 6 March, 2009, that /8 will form a dedicated pool to facilitate IPv6 Deployment. Subsequently, all IPv4 addresses received by ARIN regardless of source, except addresses to be reissued under a section 8.3 directed transfer, will be added to this pool. Allocations and assignments from this block must be justified by immediate IPv6 deployment requirements. Examples of such needs include: + IPv4 addresses for key dual stack DNS servers + NAT-PT + IVI + NAT464 translators ARIN staff will use their discretion in determining whether a particular application is meets the spirit of this policy. 4.10.1 Reservation All space assigned or allocated under this policy will be reserved in advance for a maximum period of 36 months, requests for shorter reservations will be accepted. The total reservation size will be rounded up to a CIDR bit boundary. Each organization's reserved IPv4 space will be divided into one portion per quarter. If a shorter reservation is requested such that a quarterly allotment does not match a CIDR boundary, then each quarter's allotment except the last quarter shall be increased as needed to align on a CIDR bit boundary. The final quarter will receive only the space remaining in the full reservation. An org may request one reservation in a 36 month period under each provision listed in section 4.10.4. 4.10.2 Addressing Plan Any organization wishing to recieve IPv4 addresses through this policy must submit a detailed addressing plan for each request made containing the following: (a) Their addressing needs over the entire reservation period and (b) Methods of meeting all requisite requirements (requirments are explained in section 4.10.4.) over the entire reservation period. If the submitted plan is accepted by ARIN staff as being in compliance with section 4.10.4, a reservation will be established and the first quarterly allotment of the organization's reservation will be assigned. 4.10.3 Quarterly Obligations Once a reservation has been made by ARIN, the organization holding that reservation may request one additional portion of their reserved block each quarter until their reservation is exhausted or revoked. For purposes of this computation, space received under each provision shall be considered separately if an organization has received resources through multiple provisions. In order to recieve each additional portion, the organization must submit proof that: (a) The most recent 4.10 allocation/assignment is at least 80% utilized. (b) All utilization is permitted under the 4.10.4 category for which it was initially requested. (c) ll prior 4.10 allocation/assignments within the same 4.10.4 category are at least 90% utilized. Organizations must meet all obligations as above each quarter. An organization that fails only on utilization do to unanticipated address conservation shall not be penalized, but, such organization shall not receive an additional quarterly allotment until all obligations are met. An organization which does not receive a quarterly allotment for three consecutive quarters shall forfeit the remainder of their reservation and may reapply. If an organization does not meet all obligations in any given quarter, that organization shall have their reservation reduced by one quarterly allotment which shall be returned to the transition pool. If an organization does not meet all obligations for three consecutive quarters, that organization forfeits the remainder of their reserved block. If an organization is using space received under 4.10 in a manner contrary to 4.10 et seq. that organization forfeits their remaining reservation and may have their entire allocation or assignment revoked. All 4.10. space forfeited, revoked or otherwise reclaimed shall be returned to the ARIN transition pool and shall be exempt from any requirement to return space to the IANA. 4.10.4 Specific types of transitional uses have specific requirements: (a) An ISP/LIR may request a block no smaller than a /24 nor larger than a /18 per quarter to be used to provide single IPv4 /32s to their customers which could justify a /28 or more of IPv4 under ARIN policies in effect at the time of IANA depletion. 1. No customer site may receive more than a single IPv4 /32 under this provision. 2. The customer must not have any other IPv4 allocations or assignments from the provider at the time of this assignment. 3. The customer must not have any direct assignments from ARIN at the time of this assignment. 4. The customer must not have more than a single IPv4 /32 from any other provider at the time of this assignment. 5. The customer must have IPv6 addresses with IPv6 connectivity to the ISP/LIR (must be dual-stacked). 6. The ISP/LIR must demonstrate that it already provides IPv6 addressing and connectivity to at least one existing customer for each /32 requested, up to 90% of their total customer base. 7. No organization shall receive more than a total of a /14 or equivalent under this section. (b) An ISP/LIR or End user organization may request a block no smaller than a /28 and no larger than a /23 per quarter to provide single IPv4 /32s to each physical server used to provide Internet reachable content. 1. Space issued under this provision is an assignment, not an allocation. An LIR may not distribute this space to their customers. 2. No server may recieve more than a single IPv4 /32 under this provision. 3. The server must have IPv6 addresses with IPv6 connectivity (must be dual-stacked). 4. The recieving organization must demonstrate that it already provides IPv6 addressing and connectivity to at least one existing server in addition to the server for which each /32 is requested, up to 100% of their total server base. (organizations which can show 100% dual stack are exempt from this requirement). 5. The recieving organization must IPv6 enable all of their content on the following schedule: + 25% of content IPv6 reachable within six months of receiving their first addresses under this policy + 50% of content IPv6 reachable within one year of receiving their first addresses under this policy + 75% of content IPv6 reachable within 18 months of receiving their first addresses under this policy + 90% of content IPv6 reachable within 24 months of receiving their first addresses under this policy 6. No organization shall receive more than a total of a /16 or equivalent under this section. (c) An ISP/LIR or End user organization may request a block no smaller than a /29 and no larger than a /25 per quarter for purposes relevant to their ability to deploy IPv6. 1. Space issued under this provision is an assignment, not an allocation. An LIR may not distribute this space to their customers. 2. Space issued under this provision must be used to provide the required public IPv4 address(es) for transitional technologies operated by the recipient organization. Specific examples of permitted uses are: a. Large scale or "Carrier Grade" NAT b. NAT-PT c. DS-LITE/B4/AFTeR d. IVI e. DNS64 or other transitional DNS enablers f. For other technologies of similar purpose and scope. 3. A /10 from the final /8 shall be reserved for issuance under this provision. In no case shall any addresses from this /10 be issued for any purpose outside of 4.10.4(c). (d) Applications which would qualify for IPv4 under section 4.4 of the NRPM (critical infrastructure) may qualify for IPv4 space under this policy if they meet the following criteria: 1. The critical infrastructure to be numbered must also have IPv6 addresses and must provide all services provided on IPv4 over IPv6 on the same time table. 2. Assignments under this provision shall be the smallest technically feasible size for the critical infrastructure in question. 3. The total space assigned under this provision shall not exceed the equivalent of a /14. (e) A content distribution network providing SSL terminations for SSL application or content acceleration may receive space under the following conditions: 1. No organization shall receive more than an aggregate /20 under this provision. 2. For each /32 issued under this provision, there must be at least 8 unique SSL named terminations converted to dual stack. (A unique named termination is one in which the certificate DistinguishedName and/or SubjectAltName is unique as well as the IP address terminating the connection). An organization which can show that they have dual stacked 100% of their SSL terminations shall be exempted from this requirement. 3. The total space issued under this provision shall not exceed an aggregate /11 or equivalent. From leo.vegoda at icann.org Wed Sep 15 12:50:26 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 15 Sep 2010 09:50:26 -0700 Subject: [arin-ppml] 2010-8: Rework of IPv6 assignment criteria In-Reply-To: <4C8F29DA.8020003@umn.edu> References: <4C8F29DA.8020003@umn.edu> Message-ID: Hi, On 14 Sep 2010, at 12:52, David Farmer wrote: [...] > d. By providing a reasonable technical justification indicating why IPv6 > addresses from an ISP or other LIR are unsuitable. > > Examples of justifications for why addresses from an ISP or other LIR > may be unsuitable include, but are not limited to: > > ? An organization that operates infrastructure critical to life safety > or the functioning of society can justify the need for an assignment > based on the fact that renumbering would have a broader than expected > impact than simply the number of hosts directly involved. These would > include: hospitals, fire fighting, police, emergency response, power or > energy distribution, water or waste treatment, traffic management and > control, etc? I suspect it would be useful to readers of the eventual policy to also include examples of organizations that would not qualify, so that potential applicants can identify where their organization fits on the scale. [...] > The HD-Ratio is replaced with a simplified 75% utilization threshold > based on nibble boundaries for end-user assignments. This threshold is > somewhat more restrictive for larger assignments, while slightly less > restrictive for the smaller /44 assignments, than the HD-Ratio. > However, in both cases it is much easier for an end-user to understand > the policy criteria that applies to them. This means that a different type of measure would be applied to allocations made to ISPs and assignments made to end users. Presumably, the reason for the difference is not that end user organizations are not capable of understanding the HD-ratio concept. And anyway, if it is difficult to understand, ARIN can be asked to produce explanatory materials. If the concept underlying the HD-ratio is fair, is it fair not to use that concept when calculating the amount of space available to an end-user organization? Regards, Leo Vegoda From owen at delong.com Wed Sep 15 14:06:30 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 15 Sep 2010 11:06:30 -0700 Subject: [arin-ppml] 2010-8: Rework of IPv6 assignment criteria In-Reply-To: References: <4C8F29DA.8020003@umn.edu> Message-ID: > >> The HD-Ratio is replaced with a simplified 75% utilization threshold >> based on nibble boundaries for end-user assignments. This threshold is >> somewhat more restrictive for larger assignments, while slightly less >> restrictive for the smaller /44 assignments, than the HD-Ratio. >> However, in both cases it is much easier for an end-user to understand >> the policy criteria that applies to them. > > This means that a different type of measure would be applied to allocations made to ISPs and assignments made to end users. Presumably, the reason for the difference is not that end user organizations are not capable of understanding the HD-ratio concept. And anyway, if it is difficult to understand, ARIN can be asked to produce explanatory materials. > > If the concept underlying the HD-ratio is fair, is it fair not to use that concept when calculating the amount of space available to an end-user organization? > Leo, HD-Ratio is intended to take into account the losses due to hierarchy inherent in scaling provider networks. End user networks tend to be flatter (within a given site) and thus not subject to those losses. As such, we felt that a simpler, easier to understand guideline was more appropriate to the circumstance. I'm not 100% convinced HD Ratio i a particularly good measure for ISPs, but, that's not the policy section we're fixing with this proposal. Certainly, I don't think it makes sense to saddle the end user policy with this metric just because it hasn't been used for ISPs as yet. Owen From leo.vegoda at icann.org Wed Sep 15 16:22:49 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 15 Sep 2010 13:22:49 -0700 Subject: [arin-ppml] 2010-8: Rework of IPv6 assignment criteria In-Reply-To: References: <4C8F29DA.8020003@umn.edu> Message-ID: <43BDB97B-3ADA-4FD2-85E6-5EFAAFC39E8C@icann.org> On 15 Sep 2010, at 11:06, Owen DeLong wrote: [...] > HD-Ratio is intended to take into account the losses due to hierarchy inherent in scaling provider networks. > > End user networks tend to be flatter (within a given site) and thus not subject to those losses. Some are but larger end user networks may well have similar hierarchies. It seems unfair to lump all kind of end user network operators into a single pot. > As such, we felt that a simpler, easier to understand guideline was more appropriate to the circumstance. > I'm not 100% convinced HD Ratio i a particularly good measure for ISPs, but, that's not the policy section > we're fixing with this proposal. Certainly, I don't think it makes sense to saddle the end user policy with > this metric just because it hasn't been used for ISPs as yet. I'm not sure what you mean by stating that the HD-ratio has not yet been used for ISPs yet. Isn't it used to assess the initial allocation size when the ISP needs more than a /32? Regards, Leo Vegoda From danny at tcb.net Thu Sep 16 13:29:32 2010 From: danny at tcb.net (Danny McPherson) Date: Thu, 16 Sep 2010 13:29:32 -0400 Subject: [arin-ppml] What is a "host"? In-Reply-To: References: Message-ID: <3026D718-E8C1-4549-9E85-FB9C2139FC68@tcb.net> On Sep 13, 2010, at 7:36 PM, Hannigan, Martin wrote: >> >> Classically (read: not IPv6), a host is any device that speaks TCP/IP. >> Node is used interchangeably while other terms are used to specify >> specific types of host, such as a router. >> >> >> Officially in IPv6: http://www.ietf.org/rfc/rfc4294.txt >> One other useful references in this context is: Principles of Internet Host Configuration Of course, I think device multi-homiing, virtualization and application-level configuration options (e.g., layering violations) continue to blur and complicate clear demarcation, introduce complexity and cause operational badness. -danny From owen at delong.com Thu Sep 16 15:08:26 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 16 Sep 2010 12:08:26 -0700 Subject: [arin-ppml] What is a "host"? In-Reply-To: <3026D718-E8C1-4549-9E85-FB9C2139FC68@tcb.net> References: <3026D718-E8C1-4549-9E85-FB9C2139FC68@tcb.net> Message-ID: I think the simplest useful definition of a host in an IPv6 context is: Each link local address present on the network segment constitutes a host. Owen On Sep 16, 2010, at 10:29 AM, Danny McPherson wrote: > > On Sep 13, 2010, at 7:36 PM, Hannigan, Martin wrote: >>> >>> Classically (read: not IPv6), a host is any device that speaks TCP/IP. >>> Node is used interchangeably while other terms are used to specify >>> specific types of host, such as a router. >>> >>> >>> Officially in IPv6: http://www.ietf.org/rfc/rfc4294.txt >>> > > One other useful references in this context is: > > Principles of Internet Host Configuration > > Of course, I think device multi-homiing, virtualization and application-level > configuration options (e.g., layering violations) continue to blur and complicate > clear demarcation, introduce complexity and cause operational badness. > > -danny > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From Vaughn at SwiftSystems.com Thu Sep 16 15:12:55 2010 From: Vaughn at SwiftSystems.com (Vaughn Thurman - Swift Systems Inc) Date: Thu, 16 Sep 2010 15:12:55 -0400 Subject: [arin-ppml] What is a "host"? In-Reply-To: References: <3026D718-E8C1-4549-9E85-FB9C2139FC68@tcb.net> Message-ID: <03aa01cb55d3$2b09bcf0$811d36d0$@com> Then why not just call it a unique IP address? The less we have to code our definitions, the better IMHO. ~Vaughn -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Thursday, September 16, 2010 3:08 PM To: Danny McPherson Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] What is a "host"? I think the simplest useful definition of a host in an IPv6 context is: Each link local address present on the network segment constitutes a host. Owen On Sep 16, 2010, at 10:29 AM, Danny McPherson wrote: > > On Sep 13, 2010, at 7:36 PM, Hannigan, Martin wrote: >>> >>> Classically (read: not IPv6), a host is any device that speaks TCP/IP. >>> Node is used interchangeably while other terms are used to specify >>> specific types of host, such as a router. >>> >>> >>> Officially in IPv6: http://www.ietf.org/rfc/rfc4294.txt >>> > > One other useful references in this context is: > > Principles of Internet Host Configuration > > Of course, I think device multi-homiing, virtualization and application-level > configuration options (e.g., layering violations) continue to blur and complicate > clear demarcation, introduce complexity and cause operational badness. > > -danny > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From owen at delong.com Thu Sep 16 15:21:18 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 16 Sep 2010 12:21:18 -0700 Subject: [arin-ppml] What is a "host"? In-Reply-To: <03aa01cb55d3$2b09bcf0$811d36d0$@com> References: <3026D718-E8C1-4549-9E85-FB9C2139FC68@tcb.net> <03aa01cb55d3$2b09bcf0$811d36d0$@com> Message-ID: <984E935A-E2BE-4D5D-B24E-A81CE9523373@delong.com> Because there can be 30, 50, or even 1,000 unique IP addresses on an interface, but, only one link local. Owen On Sep 16, 2010, at 12:12 PM, Vaughn Thurman - Swift Systems Inc wrote: > Then why not just call it a unique IP address? The less we have to code our > definitions, the better IMHO. > > ~Vaughn > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Owen DeLong > Sent: Thursday, September 16, 2010 3:08 PM > To: Danny McPherson > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] What is a "host"? > > I think the simplest useful definition of a host in an IPv6 context is: > > Each link local address present on the network segment constitutes a host. > > Owen > > On Sep 16, 2010, at 10:29 AM, Danny McPherson wrote: > >> >> On Sep 13, 2010, at 7:36 PM, Hannigan, Martin wrote: >>>> >>>> Classically (read: not IPv6), a host is any device that speaks TCP/IP. >>>> Node is used interchangeably while other terms are used to specify >>>> specific types of host, such as a router. >>>> >>>> >>>> Officially in IPv6: http://www.ietf.org/rfc/rfc4294.txt >>>> >> >> One other useful references in this context is: >> >> Principles of Internet Host Configuration > >> >> Of course, I think device multi-homiing, virtualization and > application-level >> configuration options (e.g., layering violations) continue to blur and > complicate >> clear demarcation, introduce complexity and cause operational badness. >> >> -danny >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From Vaughn at SwiftSystems.com Thu Sep 16 15:32:16 2010 From: Vaughn at SwiftSystems.com (Vaughn Thurman - Swift Systems Inc) Date: Thu, 16 Sep 2010 15:32:16 -0400 Subject: [arin-ppml] What is a "host"? In-Reply-To: <984E935A-E2BE-4D5D-B24E-A81CE9523373@delong.com> References: <3026D718-E8C1-4549-9E85-FB9C2139FC68@tcb.net> <03aa01cb55d3$2b09bcf0$811d36d0$@com> <984E935A-E2BE-4D5D-B24E-A81CE9523373@delong.com> Message-ID: <040e01cb55d5$df1680a0$9d4381e0$@com> Huh? :- ) What about a multi-NIC device with the same IP's bound to multiple interfaces? What about proxy arp? (i.e. What about load sharing, load balancing, or bridging systems that ARP for addresses that are also on interfaces on discrete network segments behind them?) Do we call that one address two hosts? The concepts OF TCP and UDP ports, NAT and PAT overloading, NIC teaming, and other ARP tricks all make this VERY fuzzy. Seriously. Why don't we just leave hosts to mean a device that speak IP, and really begin to speak about IP addresses when we quantify things instead of hosts. Hosts are getting fuzzier by the day, but an IP address is an IP address, is an IP address. IMHO. ~Vaughn -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Thursday, September 16, 2010 3:21 PM To: Vaughn Thurman - Swift Systems Inc Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] What is a "host"? Because there can be 30, 50, or even 1,000 unique IP addresses on an interface, but, only one link local. Owen On Sep 16, 2010, at 12:12 PM, Vaughn Thurman - Swift Systems Inc wrote: > Then why not just call it a unique IP address? The less we have to code our > definitions, the better IMHO. > > ~Vaughn > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Owen DeLong > Sent: Thursday, September 16, 2010 3:08 PM > To: Danny McPherson > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] What is a "host"? > > I think the simplest useful definition of a host in an IPv6 context is: > > Each link local address present on the network segment constitutes a host. > > Owen > > On Sep 16, 2010, at 10:29 AM, Danny McPherson wrote: > >> >> On Sep 13, 2010, at 7:36 PM, Hannigan, Martin wrote: >>>> >>>> Classically (read: not IPv6), a host is any device that speaks TCP/IP. >>>> Node is used interchangeably while other terms are used to specify >>>> specific types of host, such as a router. >>>> >>>> >>>> Officially in IPv6: http://www.ietf.org/rfc/rfc4294.txt >>>> >> >> One other useful references in this context is: >> >> Principles of Internet Host Configuration > >> >> Of course, I think device multi-homiing, virtualization and > application-level >> configuration options (e.g., layering violations) continue to blur and > complicate >> clear demarcation, introduce complexity and cause operational badness. >> >> -danny >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From bill at herrin.us Thu Sep 16 16:13:29 2010 From: bill at herrin.us (William Herrin) Date: Thu, 16 Sep 2010 16:13:29 -0400 Subject: [arin-ppml] What is a "host"? In-Reply-To: References: <3026D718-E8C1-4549-9E85-FB9C2139FC68@tcb.net> Message-ID: On Thu, Sep 16, 2010 at 3:08 PM, Owen DeLong wrote: > I think the simplest useful definition of a host in an IPv6 context is: > > Each link local address present on the network segment constitutes a host. Hi Owen, IPv6 already has a formal, accepted standard on the definition of "host." The above isn't it. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From farmer at umn.edu Thu Sep 16 17:18:40 2010 From: farmer at umn.edu (David Farmer) Date: Thu, 16 Sep 2010 16:18:40 -0500 Subject: [arin-ppml] 2010-8: Rework of IPv6 assignment criteria In-Reply-To: References: <4C8F29DA.8020003@umn.edu> Message-ID: <4C9289B0.7030403@umn.edu> On 9/15/10 11:50 CDT, Leo Vegoda wrote: > Hi, > > On 14 Sep 2010, at 12:52, David Farmer wrote: > > [...] > >> d. By providing a reasonable technical justification indicating why IPv6 >> addresses from an ISP or other LIR are unsuitable. >> >> Examples of justifications for why addresses from an ISP or other LIR >> may be unsuitable include, but are not limited to: >> >> ? An organization that operates infrastructure critical to life safety >> or the functioning of society can justify the need for an assignment >> based on the fact that renumbering would have a broader than expected >> impact than simply the number of hosts directly involved. These would >> include: hospitals, fire fighting, police, emergency response, power or >> energy distribution, water or waste treatment, traffic management and >> control, etc? > > I suspect it would be useful to readers of the eventual policy to also include examples of organizations that would not qualify, so that potential applicants can identify where their organization fits on the scale. This is useful feed back and I will consider adding examples that would not qualify as well as those that do. If anyone has idea along these lines, I would appreciate if you send them my way. However, I don't anticipate being able to get an additional update completed before the text must be frozen next week. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From danny at tcb.net Thu Sep 16 17:44:47 2010 From: danny at tcb.net (Danny McPherson) Date: Thu, 16 Sep 2010 17:44:47 -0400 Subject: [arin-ppml] What is a "host"? In-Reply-To: <040e01cb55d5$df1680a0$9d4381e0$@com> References: <3026D718-E8C1-4549-9E85-FB9C2139FC68@tcb.net> <03aa01cb55d3$2b09bcf0$811d36d0$@com> <984E935A-E2BE-4D5D-B24E-A81CE9523373@delong.com> <040e01cb55d5$df1680a0$9d4381e0$@com> Message-ID: On Sep 16, 2010, at 3:32 PM, Vaughn Thurman - Swift Systems Inc wrote: > Huh? :- ) > > What about a multi-NIC device with the same IP's bound to multiple > interfaces? What about proxy arp? (i.e. What about load sharing, load > balancing, or bridging systems that ARP for addresses that are also on > interfaces on discrete network segments behind them?) Do we call that one > address two hosts? The concepts OF TCP and UDP ports, NAT and PAT > overloading, NIC teaming, and other ARP tricks all make this VERY fuzzy. > > Seriously. Why don't we just leave hosts to mean a device that speak IP, > and really begin to speak about IP addresses when we quantify things instead > of hosts. Hosts are getting fuzzier by the day, but an IP address is an IP > address, is an IP address. IMHO. Hey Vaughn, you forgot "cloud", and virtualization, VMs, and a slew of VMs on a hypervisor, and....... I agree, things are getting fuzzier! -danny From owen at delong.com Thu Sep 16 17:50:11 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 16 Sep 2010 14:50:11 -0700 Subject: [arin-ppml] What is a "host"? In-Reply-To: References: <3026D718-E8C1-4549-9E85-FB9C2139FC68@tcb.net> Message-ID: <1D9BBB97-580C-4F6D-B73F-B638CBC5C049@delong.com> On Sep 16, 2010, at 1:13 PM, William Herrin wrote: > On Thu, Sep 16, 2010 at 3:08 PM, Owen DeLong wrote: >> I think the simplest useful definition of a host in an IPv6 context is: >> >> Each link local address present on the network segment constitutes a host. > > Hi Owen, > > IPv6 already has a formal, accepted standard on the definition of > "host." The above isn't it. > True, but, the accepted standard definition isn't particularly useful for IP policy purposes. Owen From michael.dillon at bt.com Fri Sep 17 06:05:14 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 17 Sep 2010 11:05:14 +0100 Subject: [arin-ppml] What is a "host"? In-Reply-To: <984E935A-E2BE-4D5D-B24E-A81CE9523373@delong.com> References: <3026D718-E8C1-4549-9E85-FB9C2139FC68@tcb.net> <03aa01cb55d3$2b09bcf0$811d36d0$@com> <984E935A-E2BE-4D5D-B24E-A81CE9523373@delong.com> Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B42391CF4E005@EMV01-UKBR.domain1.systemhost.net> > > Each link local address present on the network segment constitutes a > host. > Because there can be 30, 50, or even 1,000 unique IP addresses on an > interface, but, only one link local. This is far too technically complex for something that goes into policy. In order to figure out how this impacts a given organization you need to get a technical person involved who can find out how many link local addresses appear on a network segment. An ordinary person has no way of knowing this, and could easily buy some equipment that fails this test and therefore puts their ARIN allocations at risk. And this does not address the main issue which is virtualization of servers, networks, switches and routers. For instance, do virtual network segments count? Policy needs to be straightforward and avoid these kinds of technically complex tests which would require ARIN to send an engineer with test equipment to determine whether the test passes or fails. --Michael Dillon From bill at herrin.us Fri Sep 17 08:24:30 2010 From: bill at herrin.us (William Herrin) Date: Fri, 17 Sep 2010 08:24:30 -0400 Subject: [arin-ppml] What is a "host"? In-Reply-To: <1D9BBB97-580C-4F6D-B73F-B638CBC5C049@delong.com> References: <3026D718-E8C1-4549-9E85-FB9C2139FC68@tcb.net> <1D9BBB97-580C-4F6D-B73F-B638CBC5C049@delong.com> Message-ID: On Thu, Sep 16, 2010 at 5:50 PM, Owen DeLong wrote: > On Sep 16, 2010, at 1:13 PM, William Herrin wrote: >> IPv6 already has a formal, accepted standard on the definition of >> "host." The above isn't it. >> > True, but, the accepted standard definition isn't particularly useful > for IP policy purposes. Then don't use the word host in IPv6 policy. There are plenty of words in the dictionary that haven't yet been given a standardized meaning in IPv6. Pick one. Better yet, don't use the concept of a host. It doesn't fit. Unlike IPv4, IPv6 was deliberately designed to accommodate a functionally infinite number of hosts on any given network segment. The addressing driver is how many segments you need to break your network in to. Regards, Bill -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Vaughn at SwiftSystems.com Fri Sep 17 14:11:53 2010 From: Vaughn at SwiftSystems.com (Vaughn Thurman - Swift Systems Inc) Date: Fri, 17 Sep 2010 14:11:53 -0400 Subject: [arin-ppml] What is a "host"? In-Reply-To: <0F29D1BA57992E4CAB5AD2C9AE7B42391CF4E005@EMV01-UKBR.domain1.systemhost.net> References: <3026D718-E8C1-4549-9E85-FB9C2139FC68@tcb.net> <03aa01cb55d3$2b09bcf0$811d36d0$@com> <984E935A-E2BE-4D5D-B24E-A81CE9523373@delong.com> <0F29D1BA57992E4CAB5AD2C9AE7B42391CF4E005@EMV01-UKBR.domain1.systemhost.net> Message-ID: <009e01cb5693$ce615e60$6b241b20$@com> Though I showed my executive IP rust using ARP to make a point similar to this, I agree with the well articulated response below. We need to avoid using words that lead to arguable definitions that in turn lead to arguable interpretations as to the application of technology. It's too circular. Host, can mean a whole host of things now (excuse the pun) and it should be abandoned, and link local should not replace it. ~V >Policy needs to be straightforward and avoid these kinds of technically >complex tests which would require ARIN to send an engineer with test >equipment to determine whether the test passes or fails. -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of michael.dillon at bt.com Sent: Friday, September 17, 2010 6:05 AM To: arin-ppml at arin.net Subject: Re: [arin-ppml] What is a "host"? > > Each link local address present on the network segment constitutes a > host. > Because there can be 30, 50, or even 1,000 unique IP addresses on an > interface, but, only one link local. This is far too technically complex for something that goes into policy. In order to figure out how this impacts a given organization you need to get a technical person involved who can find out how many link local addresses appear on a network segment. An ordinary person has no way of knowing this, and could easily buy some equipment that fails this test and therefore puts their ARIN allocations at risk. And this does not address the main issue which is virtualization of servers, networks, switches and routers. For instance, do virtual network segments count? Policy needs to be straightforward and avoid these kinds of technically complex tests which would require ARIN to send an engineer with test equipment to determine whether the test passes or fails. --Michael Dillon _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From owen at delong.com Fri Sep 17 14:33:59 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 17 Sep 2010 11:33:59 -0700 Subject: [arin-ppml] What is a "host"? In-Reply-To: <0F29D1BA57992E4CAB5AD2C9AE7B42391CF4E005@EMV01-UKBR.domain1.systemhost.net> References: <3026D718-E8C1-4549-9E85-FB9C2139FC68@tcb.net> <03aa01cb55d3$2b09bcf0$811d36d0$@com> <984E935A-E2BE-4D5D-B24E-A81CE9523373@delong.com> <0F29D1BA57992E4CAB5AD2C9AE7B42391CF4E005@EMV01-UKBR.domain1.systemhost.net> Message-ID: <95E4C0A8-4A81-4D0B-8FA1-BB65AC0244E5@delong.com> On Sep 17, 2010, at 3:05 AM, wrote: > >>> Each link local address present on the network segment constitutes a >> host. > >> Because there can be 30, 50, or even 1,000 unique IP addresses on an >> interface, but, only one link local. > > This is far too technically complex for something that goes into policy. > In order to figure out how this impacts a given organization you need to > get a technical person involved who can find out how many link local > addresses appear on a network segment. An ordinary person has no way > of knowing this, and could easily buy some equipment that fails this > test and therefore puts their ARIN allocations at risk. > In essence it says count the number of IPv6-active NICs. You can't have an IPv6-active NIC without an IPv6 link-local address. Unfortunately, the terms NIC, interface, etc. have all become so overloaded and convoluted that there is no way to given them consistent meaning, so, I resorted to link-local addresses as a way to describe them accurately for purposes of policy. How do you buy equipment that uses IPv6 and fails this test? I don't believe that is possible since you can't have IPv6 on an interface without a link-local address on the interface. IP Address allocations are not handled by people so completely non-technical that they can't count the number of interfaces that require IPv6 addresses. If they are, then, that organization needs to hire someone that can count NICs to handle their IP address policy interactions. > And this does not address the main issue which is virtualization of > servers, networks, switches and routers. For instance, do virtual network > segments count? > Each virtual interface on the virtual network segment would have a link local if it supported IPv6, so, yes, they would count. > Policy needs to be straightforward and avoid these kinds of technically > complex tests which would require ARIN to send an engineer with test > equipment to determine whether the test passes or fails. > You are reading _WAY_ too much into it beyond the intent. If you have an interface that is speaking IPv6, it should count as one host. If you have 20 interfaces speaking IPv6, they should count as 20 hosts. If you have 5 interfaces in a NIC-Team speaking IPv6, they should count as one host. Really, counting up the number of things that require an IPv6 link local address is _NOT_ rocket science, nor is it technically complex. Owen From mksmith at adhost.com Fri Sep 17 17:39:36 2010 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Fri, 17 Sep 2010 14:39:36 -0700 Subject: [arin-ppml] What is a "host"? In-Reply-To: <95E4C0A8-4A81-4D0B-8FA1-BB65AC0244E5@delong.com> References: <3026D718-E8C1-4549-9E85-FB9C2139FC68@tcb.net><03aa01cb55d3$2b09bcf0$811d36d0$@com><984E935A-E2BE-4D5D-B24E-A81CE9523373@delong.com><0F29D1BA57992E4CAB5AD2C9AE7B42391CF4E005@EMV01-UKBR.domain1.systemhost.net> <95E4C0A8-4A81-4D0B-8FA1-BB65AC0244E5@delong.com> Message-ID: <17838240D9A5544AAA5FF95F8D52031608F03E94@ad-exh01.adhost.lan> > > Really, counting up the number of things that require an IPv6 link > local address is _NOT_ rocket science, nor is it technically complex. > > Owen > Nor is it the appropriate concept for creating policy if that is the definition. I have four web servers in a load-balanced pool, each with one NIC. So, as per your definition, they are only 4 hosts. But, on each of those servers, I have multiple /64's assigned, one for each customer. They have to be discrete /64's for the load balancing to work. So far I have provisioned 20 customers, so I have 80 /64's that are assigned across 4 NICs. Does this mean I still only have 4 hosts? Although I have 20 customers? And 80 /64's? Rather than argue about the definition of host, I would rather the term be abandoned all together and something more inclusive be used. I am not misusing addresses in my configuration but none of those allocations would be appropriate if "host" is the defining baseline. Regards, Mike From farmer at umn.edu Fri Sep 17 20:11:33 2010 From: farmer at umn.edu (David Farmer) Date: Fri, 17 Sep 2010 19:11:33 -0500 Subject: [arin-ppml] What is a "host"? In-Reply-To: <17838240D9A5544AAA5FF95F8D52031608F03E94@ad-exh01.adhost.lan> References: <3026D718-E8C1-4549-9E85-FB9C2139FC68@tcb.net><03aa01cb55d3$2b09bcf0$811d36d0$@com><984E935A-E2BE-4D5D-B24E-A81CE9523373@delong.com><0F29D1BA57992E4CAB5AD2C9AE7B42391CF4E005@EMV01-UKBR.domain1.systemhost.net> <95E4C0A8-4A81-4D0B-8FA1-BB65AC0244E5@delong.com> <17838240D9A5544AAA5FF95F8D52031608F03E94@ad-exh01.adhost.lan> Message-ID: <4C9403B5.1010903@umn.edu> On 9/17/10 16:39 CDT, Michael K. Smith - Adhost wrote: >> >> Really, counting up the number of things that require an IPv6 link >> local address is _NOT_ rocket science, nor is it technically complex. >> >> Owen >> > Nor is it the appropriate concept for creating policy if that is the > definition. I have four web servers in a load-balanced pool, each with > one NIC. So, as per your definition, they are only 4 hosts. But, on > each of those servers, I have multiple /64's assigned, one for each > customer. They have to be discrete /64's for the load balancing to > work. So far I have provisioned 20 customers, so I have 80 /64's that > are assigned across 4 NICs. Does this mean I still only have 4 hosts? > Although I have 20 customers? And 80 /64's? > > Rather than argue about the definition of host, I would rather the term > be abandoned all together and something more inclusive be used. I am > not misusing addresses in my configuration but none of those allocations > would be appropriate if "host" is the defining baseline. I understand all of the issues with word "host". However, I believe the policy intent is clear, but I'm open to suggestions for different wording to use. Beyond that I would like to ask everyone to take a step back and look at the over all intent, there are four clauses, and only one of them has to be meet; ----- a. Having a previously justified IPv4 end-user assignment from ARIN or one of its predecessor registries, or; b. Currently being IPv6 Multihomed or immediately becoming IPv6 Multihomed and using an assigned valid global AS number, or; c. By having a network consisting of a total of 1000 or more hosts, or; d. By providing a reasonable technical justification indicating why IPv6 addresses from an ISP or other LIR are unsuitable. ---- So, you qualify for IPv6, if; a. You already have IPv4 space. Most people would consider it a barrier to entry for IPv6 if they already had IPv4 PI and couldn't get IPv6 PI. This is consistent with the current policy and worded identically to the new language just implemented in 6.5.1.2.a. b. You are IPv6 multihomed. You will in all likelihood consume a route table slot anyway so you might as well have your owe IPv6 address space, and as much as you need so you only need to consume one route table slot. This is new policy, but there seems to have been a consensus for this concept and is worded identically to the new language just implemented in 6.5.1.2.b. Lets skip c. for a minute, this is crux of the issue, I'll get back to it soon; d. If you have technical reasons why addresses from an ISP or LIR are not suitable then you should be able to get address space. This is more controversial, but there has been some vocal support for this and little if any vocal opposition. Now back to the crux of this issue for this thread, clause c. Clause c. is intended to set a clear and easy to understand threshold for single connected end-users to meet in order to receive an IPv6 assignment. It is intended to restate and be based on a minimum block size of /20 or 4096 IPv4 addresses from section 4.3.2.1 Single Connection, and a 25% immediate utilization of that block from 4.3.3. Utilization rate. Giving you 1024 hosts, which I rounded down to 1000 hosts. I considered subnet counts, host counts, combinations of the two, or allowing one or the other. There are issues with all of the options. At first I left this out completely, however this too creates an issue. So, I decided to go with a host count consistent with the current IPv4 policy. What is the issue with leaving it out completely? Well, clause a. allows anyone who has IPv4 addresses to get IPv6 addresses, without clause c. a discontinuity is created at the moment of IPv4 run-out. Someone with a single connected network of 1000 hosts, who could have qualified to received both IPv4 and IPv6, after run-out may not be able to receive IPv6 addresses, at least without justifying why addresses from an ISP or LIR are not suitable for them. The moment of IPv4 run-out is not the right time to have a discontinuity in who can receive IPv6 address space. Personally, I'd be happy to eliminate clause c. sometime well after IPv4 run-out has occurred, say a year or more. What are the options from here; 1. Leave clause c. out completely. I explained why I think that is a bad idea, at least until well after IPv4 run-out. 2. Don't use the word host, how about; "c. By having a network that makes active uses of a minimum of 1000 IPv6 addresses, or;" 3. Include IPv4 policy by reference instead of restating it. One of my goals in writing this policy was to eliminate direct references to IPv4 policy in IPv6 policy. But, you think that is better policy, then how about this; "c. Qualify for an IPv4 assignment from ARIN under IPv4 policy currently in effect, or;" Do you have other suggestions? While writing this I realized I may have focused on the wrong clause of 4.3.3. Utilization rate. Now, I think it is more appropriate to focus on the second clause of that policy "A 50% utilization rate within one year" So I think I prefer replacing clause c. with the following; "c. By having a network that makes active uses of a minimum of 2000 IPv6 addresses within 12 months, or;" What do you think of that language? Feed back ASAP please, the text has to be frozen soon. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From gary.buhrmaster at gmail.com Fri Sep 17 22:32:06 2010 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Fri, 17 Sep 2010 19:32:06 -0700 Subject: [arin-ppml] What is a "host"? In-Reply-To: <4C9403B5.1010903@umn.edu> References: <3026D718-E8C1-4549-9E85-FB9C2139FC68@tcb.net> <03aa01cb55d3$2b09bcf0$811d36d0$@com> <984E935A-E2BE-4D5D-B24E-A81CE9523373@delong.com> <0F29D1BA57992E4CAB5AD2C9AE7B42391CF4E005@EMV01-UKBR.domain1.systemhost.net> <95E4C0A8-4A81-4D0B-8FA1-BB65AC0244E5@delong.com> <17838240D9A5544AAA5FF95F8D52031608F03E94@ad-exh01.adhost.lan> <4C9403B5.1010903@umn.edu> Message-ID: On Fri, Sep 17, 2010 at 17:11, David Farmer wrote: ..... > > While writing this I realized I may have focused on the wrong clause of > 4.3.3. Utilization rate. ?Now, I think it is more appropriate to focus on > the second clause of that policy "A 50% utilization rate within one year" > > So I think I prefer replacing clause c. with the following; > > "c. By having a network that makes active uses of a minimum of 2000 IPv6 > addresses within 12 months, or;" > > What do you think of that language? I would say your reasoning (and this wording) seems to be consistent with the existing policy intent, and I would say it should move forward as you have written. Gary From marty at akamai.com Sat Sep 18 02:14:39 2010 From: marty at akamai.com (Hannigan, Martin) Date: Sat, 18 Sep 2010 02:14:39 -0400 Subject: [arin-ppml] Policy Proposal 2010-10 - Global Policy for IPv4 Allocations by the IANA Post Exhaustion In-Reply-To: <4C7ED760.6050006@umn.edu> Message-ID: On 9/1/10 6:44 PM, "David Farmer" wrote: [ clip ] >> I think that we get the message with regards to the transfer section and we >> already identified that the problem with the allocation method was a >> mechanical problem and an suggested update is pending. > > Thanks, and I eagerly await the update. It has been updated. Best, -M< From farmer at umn.edu Sat Sep 18 20:00:57 2010 From: farmer at umn.edu (David Farmer) Date: Sat, 18 Sep 2010 19:00:57 -0500 Subject: [arin-ppml] 2010-8: Rework of IPv6 assignment criteria In-Reply-To: References: <4C8F29DA.8020003@umn.edu> Message-ID: <4C9552B9.4000503@umn.edu> On 9/15/10 13:06 CDT, Owen DeLong wrote: >> >>> The HD-Ratio is replaced with a simplified 75% utilization threshold >>> based on nibble boundaries for end-user assignments. This threshold is >>> somewhat more restrictive for larger assignments, while slightly less >>> restrictive for the smaller /44 assignments, than the HD-Ratio. >>> However, in both cases it is much easier for an end-user to understand >>> the policy criteria that applies to them. >> >> This means that a different type of measure would be applied to allocations made to ISPs and assignments made to end users. Yes, it would be a different measure. However, there are number of significant differences in how ISPs and end-users make use of addresses anyway. So I'm not sure a different measure is inappropriate. > Presumably, the reason for the difference is not that end user organizations are not capable of understanding the HD-ratio concept. And anyway, if it is difficult to understand, ARIN can be asked to produce explanatory materials. I want to refer people to RFC 3194: "The Host-Density Ratio for Address Assignment Efficiency: An update on the H ratio" and section 6.7 of the NRPM. https://www.arin.net/policy/nrpm.html#six7 Actually, while I believe many people do not understand HD-Ratio, especially end-users, that isn't the only issue. if it were, then "explanatory materials" could maybe solve the problem. As I see it, the HD-Ratio of /56 prefixes as applied in ARIN policy is a reasonable measure for ISPs and LIRs as they make assignments to end-users. However, I don't believe that the HD-Ratio of /56 prefixes, is a meaningful measure to apply to an end-users. With that measure, how many /64 subnets is an end-user suppose to consume out of a /56 before they can get another one? How about the same question for a /48? If they use one /64 from 184 /56s, are they entitled to an additional /48? That is one way I can read the policy, but I know most people think that you should have to use more than 184 /64 subnets to get an additional /48. >> If the concept underlying the HD-ratio is fair, is it fair not to use that concept when calculating the amount of space available to an end-user organization? Yes, it would be possible to write the policy using HD-Ratio of sties as the threshold rather than a 75% threshold. However the threshold for /44 would have been 14 sites instead of 12, so for that case I liked 75% better. This is the 75% threshold that is in the current Draft Policy; More than 1 but less than or equal to 12 sites justified, receives a /44 assignment; More than 12 but less than or equal to 192 /sites justified, receives a /40 assignment; More than 192 but less than or equal to 3,072 sites justified, receives a /36 assignment; More than 3,072 sites justified, receives a /32 assignment or larger. This would be the equilivant using HD-Ratio of /48 sites; More than 1 but less than or equal to 14 sites justified, receives a /44 assignment; More than 14 but less than or equal to 184 /sites justified, receives a /40 assignment; More than 184 but less than or equal to 2,487 sites justified, receives a /36 assignment; More than 2,487 sites justified, receives a /32 assignment or larger. I contemplated using, the 75% threshold for /44 and HD-Ratio for the rest, but it seemed even more complicated to explain the reasoning behind that idea. So, after thinking about it for a while, I decided to just go with the 75% threshold across the board. The combination of /48 per site and assigning on nibble boundaries, seems to more than makeup for the fact that the 75% threshold is a little more restrictive than HD-Ratio. And, yes the 75% threshold has the added benefit that it is much easier for most people to understand. But I have provided the numbers above so everyone can judge for themselves. > Leo, > > HD-Ratio is intended to take into account the losses due to hierarchy inherent in scaling provider networks. > > End user networks tend to be flatter (within a given site) and thus not subject to those losses. > > As such, we felt that a simpler, easier to understand guideline was more appropriate to the circumstance. While all end-user networks are not necessarily flatter, I agree the majority are. However, I think the /48 per site and assigning on nibble boundaries will serve even large hierarchical end-user networks as well as HD-Ratio in most cases. Furthermore, very large hierarchical end-user networks, especially for a large multinational corporation, are not precluded from considering themselves as an ISP or LIR, and then starting with a /32 and being able to avail themselves of HD-Ratio. That might be more appropriate anyway, the networks for large multinational corporation with many independent business units, probably have much more in common with ISPs then the majority of other end-user networks. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From Daniel_Alexander at Cable.Comcast.com Sun Sep 19 16:56:04 2010 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Sun, 19 Sep 2010 16:56:04 -0400 Subject: [arin-ppml] Updates to draft policy 2010-13 In-Reply-To: <9225625A-5D80-4A30-B091-32EADE00310B@delong.com> Message-ID: What was the problem we set out to fix here? I went back and looked at the rationale from the original draft of this proposal. The goal was to prevent potential abuse of the current section 4.10 because of possibly vague language. If this was possible, an organization could obtain up to a /24 from the /10, once every six months. This could cause the /10 to become depleted in as soon as 2.5-3.0 years, or sometime in 2014. Can someone help me understand how we got from the current policy of reserving a /10 for translation technologies and DNS servers to the current proposal text? Rather than closing possible loopholes, we would delete the current policy. We would tie up the last /8. Define what are acceptable architectures for an organization. And put ARIN in the business of short term allocation ?loans? that it would have to figure out how to validate, administer, and recall. I fail to see how 2010-13 improves section 4.10 and I currently do not support this proposal. Dan Alexander ARIN AC On 9/14/10 8:46 PM, "Owen DeLong" wrote: > Based on additional community feedback, 2010-13 has again been revised. Here > is an updated version: > > > Here is the updated text: > > Draft Policy 2010-13: Permitted Uses of Space Reserved under NRPM 4.10 > Proposal Originator: Owen DeLong > Proposal Version: 1.38 > Date: 5 September 2010 > Proposal type: modify > Policy term: permanent > Policy statement: > > Rename section 4.10: "IPv4 Transition Pool Post IANA Regular Pool Depletion" > > Replace the text of section 4.10 in it's entirety with: > > 4.10 When ARIN receives its /8 IPv4 allocation from IANA under the > global policy titled "Global Policy for the Allocation of the > Remaining IPv4 Address Space" ratified by ICANN Board > on 6 March, 2009, that /8 will form a dedicated pool to > facilitate IPv6 Deployment. > > Subsequently, all IPv4 addresses received by ARIN regardless of > source, except addresses to be reissued under a section 8.3 > directed transfer, will be added to this pool. > > Allocations and assignments from this block must be justified by > immediate IPv6 deployment requirements. > > Examples of such needs include: > + IPv4 addresses for key dual stack DNS servers > + NAT-PT > + IVI > + NAT464 translators > > ARIN staff will use their discretion in determining whether a > particular > application is meets the spirit of this policy. > > 4.10.1 Reservation > > All space assigned or allocated under this policy will be reserved > in advance for a maximum period of 36 months, requests for shorter > reservations will be accepted. The total reservation size will be > rounded up to a CIDR bit boundary. > > Each organization's reserved IPv4 space will be divided into one > portion per quarter. If a shorter reservation is requested such > that a quarterly allotment does not match a CIDR boundary, then > each quarter's allotment except the last quarter shall be > increased as needed to align on a CIDR bit boundary. The final > quarter will receive only the space remaining in the full > reservation. > > An org may request one reservation in a 36 month period under > each provision listed in section 4.10.4. > > 4.10.2 Addressing Plan > > Any organization wishing to recieve IPv4 addresses through this > policy must submit a detailed addressing plan for each request > made containing the following: > (a) Their addressing needs over the entire reservation period and > (b) Methods of meeting all requisite requirements (requirments are > explained in section 4.10.4.) over the entire reservation > period. > > If the submitted plan is accepted by ARIN staff as being in > compliance with section 4.10.4, a reservation will be established > and the first quarterly allotment of the organization's > reservation will be assigned. > > 4.10.3 Quarterly Obligations > > Once a reservation has been made by ARIN, the organization holding > that reservation may request one additional portion of their reserved > block each quarter until their reservation is exhausted or revoked. > > For purposes of this computation, space received under each > provision shall be considered separately if an organization has > received resources through multiple provisions. > > In order to recieve each additional portion, the organization must > submit proof that: > (a) The most recent 4.10 allocation/assignment is at > least 80% utilized. > (b) All utilization is permitted under the 4.10.4 category for > which it was initially requested. > (c) ll prior 4.10 allocation/assignments within the same 4.10.4 > category are at least 90% utilized. > > Organizations must meet all obligations as above each quarter. An > organization that fails only on utilization do to unanticipated > address conservation shall not be penalized, but, such organization > shall not receive an additional quarterly allotment until all > obligations are met. An organization which does not receive a > quarterly allotment for three consecutive quarters shall forfeit > the remainder of their reservation and may reapply. > > If an organization does not meet all obligations in any given > quarter, that organization shall have their reservation reduced by > one quarterly allotment which shall be returned to the transition > pool. > > If an organization does not meet all obligations for three > consecutive quarters, that organization forfeits the remainder > of their reserved block. > > If an organization is using space received under 4.10 in a manner > contrary to 4.10 et seq. that organization forfeits their remaining > reservation and may have their entire allocation or assignment > revoked. > > All 4.10. space forfeited, revoked or otherwise reclaimed shall > be returned to the ARIN transition pool and shall be exempt > from any requirement to return space to the IANA. > > 4.10.4 Specific types of transitional uses have specific > requirements: > > (a) An ISP/LIR may request a block no smaller than a /24 nor > larger than a /18 per quarter to be used to provide single > IPv4 /32s to their customers which could justify a /28 or > more of IPv4 under ARIN policies in effect at the time of > IANA depletion. > 1. No customer site may receive more than a single > IPv4 /32 under this provision. > 2. The customer must not have any other IPv4 > allocations or assignments from the provider at > the time of this assignment. > 3. The customer must not have any direct assignments > from ARIN at the time of this assignment. > 4. The customer must not have more than a single > IPv4 /32 from any other provider at the time of > this assignment. > 5. The customer must have IPv6 addresses with IPv6 > connectivity to the ISP/LIR (must be dual-stacked). > 6. The ISP/LIR must demonstrate that it already > provides IPv6 addressing and connectivity to at > least one existing customer for each /32 requested, > up to 90% of their total customer base. > 7. No organization shall receive more than a total > of a /14 or equivalent under this section. > > (b) An ISP/LIR or End user organization may request a block > no smaller than a /28 and no larger than a /23 per quarter > to provide single IPv4 /32s to each physical server used > to provide Internet reachable content. > 1. Space issued under this provision is an assignment, > not an allocation. An LIR may not distribute this > space to their customers. > 2. No server may recieve more than a single IPv4 /32 > under this provision. > 3. The server must have IPv6 addresses with IPv6 > connectivity (must be dual-stacked). > 4. The recieving organization must demonstrate that it > already provides IPv6 addressing and connectivity > to at least one existing server in addition to the > server for which each /32 is requested, up to 100% > of their total server base. (organizations which > can show 100% dual stack are exempt from this > requirement). > 5. The recieving organization must IPv6 enable all of > their content on the following schedule: > > + 25% of content IPv6 reachable within six > months of receiving their first addresses > under this policy > + 50% of content IPv6 reachable within one year > of receiving their first addresses under this > policy > + 75% of content IPv6 reachable within 18 months > of receiving their first addresses under this > policy > + 90% of content IPv6 reachable within 24 months > of receiving their first addresses under this > policy > > 6. No organization shall receive more than a total of > a /16 or equivalent under this section. > > (c) An ISP/LIR or End user organization may request a block no > smaller than a /29 and no larger than a /25 per quarter for > purposes relevant to their ability to deploy IPv6. > 1. Space issued under this provision is an assignment, > not an allocation. An LIR may not distribute this > space to their customers. > 2. Space issued under this provision must be used to > provide the required public IPv4 address(es) for > transitional technologies operated by the recipient > organization. > > Specific examples of permitted uses are: > a. Large scale or "Carrier Grade" NAT > b. NAT-PT > c. DS-LITE/B4/AFTeR > d. IVI > e. DNS64 or other transitional DNS enablers > f. For other technologies of similar purpose > and scope. > > 3. A /10 from the final /8 shall be reserved for issuance > under this provision. In no case shall any addresses > from this /10 be issued for any purpose outside > of 4.10.4(c). > > (d) Applications which would qualify for IPv4 under section 4.4 of > the NRPM (critical infrastructure) may qualify for IPv4 space > under this policy if they meet the following criteria: > 1. The critical infrastructure to be numbered must also > have IPv6 addresses and must provide all services > provided on IPv4 over IPv6 on the same time table. > 2. Assignments under this provision shall be the > smallest technically feasible size for the critical > infrastructure in question. > 3. The total space assigned under this provision shall > not > exceed the equivalent of a /14. > > (e) A content distribution network providing SSL terminations for > SSL application or content acceleration may receive space > under the following conditions: > 1. No organization shall receive more than an > aggregate /20 under this provision. > 2. For each /32 issued under this provision, there > must be at least 8 unique SSL named terminations > converted to dual stack. (A unique named termination > is one in which the certificate DistinguishedName > and/or SubjectAltName is unique as well as the IP > address terminating the connection). An organization > which can show that they have dual stacked 100% of > their SSL terminations shall be exempted from this > requirement. > 3. The total space issued under this provision shall > not exceed an aggregate /11 or equivalent. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Sun Sep 19 19:26:47 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 19 Sep 2010 16:26:47 -0700 Subject: [arin-ppml] Updates to draft policy 2010-13 In-Reply-To: References: Message-ID: <9690F32F-70B2-463C-BB54-E7EC2C48AFDD@delong.com> On Sep 19, 2010, at 1:56 PM, Alexander, Daniel wrote: > > What was the problem we set out to fix here? I went back and looked at the rationale from the original draft of this proposal. The goal was to prevent potential abuse of the current section 4.10 because of possibly vague language. If this was possible, an organization could obtain up to a /24 from the /10, once every six months. This could cause the /10 to become depleted in as soon as 2.5-3.0 years, or sometime in 2014. I'm not sure how you arrived at your figures or your understanding of the original goal. The original goal was to create criteria under which space from 4.10 could actually get issued by ARIN based on feedback from staff that the original policy didn't really given them sufficient guidance. How we got here was an effort to achieve a rational compromise between the goals of 4.10 and the needs of several other segments of the community in order to broaden support for the proposal. > > Can someone help me understand how we got from the current policy of reserving a /10 for translation technologies and DNS servers to the current proposal text? Rather than closing possible loopholes, we would delete the current policy. We would tie up the last /8. Define what are acceptable architectures for an organization. And put ARIN in the business of short term allocation ?loans? that it would have to figure out how to validate, administer, and recall. > I don't think you are making a valid characterization of the current proposal text. Yes, the new proposal ties up the entire /8. It does not define what are acceptable architectures for any organization. It merely places tighter restrictions on address space from that last /8 in order to facilitate and encourage IPv6 deployment. I have no idea what you mean by short term allocation "loans". I don't see any part of the policy that fits that description, so, I'd like to request some clarification there as to what, specifically, you are referring to. > I fail to see how 2010-13 improves section 4.10 and I currently do not support this proposal. > Please re-evaluate this based on text that will be distributed tonight. There are a number of changes and I think the newer text is be far better. Owen > Dan Alexander > ARIN AC > > > On 9/14/10 8:46 PM, "Owen DeLong" wrote: > >> Based on additional community feedback, 2010-13 has again been revised. Here is an updated version: >> >> >> Here is the updated text: >> >> Draft Policy 2010-13: Permitted Uses of Space Reserved under NRPM 4.10 >> Proposal Originator: Owen DeLong >> Proposal Version: 1.38 >> Date: 5 September 2010 >> Proposal type: modify >> Policy term: permanent >> Policy statement: >> >> Rename section 4.10: "IPv4 Transition Pool Post IANA Regular Pool Depletion" >> >> Replace the text of section 4.10 in it's entirety with: >> >> 4.10 When ARIN receives its /8 IPv4 allocation from IANA under the >> global policy titled "Global Policy for the Allocation of the >> Remaining IPv4 Address Space" ratified by ICANN Board >> on 6 March, 2009, that /8 will form a dedicated pool to >> facilitate IPv6 Deployment. >> >> Subsequently, all IPv4 addresses received by ARIN regardless of >> source, except addresses to be reissued under a section 8.3 >> directed transfer, will be added to this pool. >> >> Allocations and assignments from this block must be justified by >> immediate IPv6 deployment requirements. >> >> Examples of such needs include: >> + IPv4 addresses for key dual stack DNS servers >> + NAT-PT >> + IVI >> + NAT464 translators >> >> ARIN staff will use their discretion in determining whether a particular >> application is meets the spirit of this policy. >> >> 4.10.1 Reservation >> >> All space assigned or allocated under this policy will be reserved >> in advance for a maximum period of 36 months, requests for shorter >> reservations will be accepted. The total reservation size will be >> rounded up to a CIDR bit boundary. >> >> Each organization's reserved IPv4 space will be divided into one >> portion per quarter. If a shorter reservation is requested such >> that a quarterly allotment does not match a CIDR boundary, then >> each quarter's allotment except the last quarter shall be >> increased as needed to align on a CIDR bit boundary. The final >> quarter will receive only the space remaining in the full >> reservation. >> >> An org may request one reservation in a 36 month period under >> each provision listed in section 4.10.4. >> >> 4.10.2 Addressing Plan >> >> Any organization wishing to recieve IPv4 addresses through this >> policy must submit a detailed addressing plan for each request >> made containing the following: >> (a) Their addressing needs over the entire reservation period and >> (b) Methods of meeting all requisite requirements (requirments are >> explained in section 4.10.4.) over the entire reservation >> period. >> >> If the submitted plan is accepted by ARIN staff as being in >> compliance with section 4.10.4, a reservation will be established >> and the first quarterly allotment of the organization's >> reservation will be assigned. >> >> 4.10.3 Quarterly Obligations >> >> Once a reservation has been made by ARIN, the organization holding >> that reservation may request one additional portion of their reserved >> block each quarter until their reservation is exhausted or revoked. >> >> For purposes of this computation, space received under each >> provision shall be considered separately if an organization has >> received resources through multiple provisions. >> >> In order to recieve each additional portion, the organization must >> submit proof that: >> (a) The most recent 4.10 allocation/assignment is at >> least 80% utilized. >> (b) All utilization is permitted under the 4.10.4 category for >> which it was initially requested. >> (c) ll prior 4.10 allocation/assignments within the same 4.10.4 >> category are at least 90% utilized. >> >> Organizations must meet all obligations as above each quarter. An >> organization that fails only on utilization do to unanticipated >> address conservation shall not be penalized, but, such organization >> shall not receive an additional quarterly allotment until all >> obligations are met. An organization which does not receive a >> quarterly allotment for three consecutive quarters shall forfeit >> the remainder of their reservation and may reapply. >> >> If an organization does not meet all obligations in any given >> quarter, that organization shall have their reservation reduced by >> one quarterly allotment which shall be returned to the transition >> pool. >> >> If an organization does not meet all obligations for three >> consecutive quarters, that organization forfeits the remainder >> of their reserved block. >> >> If an organization is using space received under 4.10 in a manner >> contrary to 4.10 et seq. that organization forfeits their remaining >> reservation and may have their entire allocation or assignment >> revoked. >> >> All 4.10. space forfeited, revoked or otherwise reclaimed shall >> be returned to the ARIN transition pool and shall be exempt >> from any requirement to return space to the IANA. >> >> 4.10.4 Specific types of transitional uses have specific requirements: >> >> (a) An ISP/LIR may request a block no smaller than a /24 nor >> larger than a /18 per quarter to be used to provide single >> IPv4 /32s to their customers which could justify a /28 or >> more of IPv4 under ARIN policies in effect at the time of >> IANA depletion. >> 1. No customer site may receive more than a single >> IPv4 /32 under this provision. >> 2. The customer must not have any other IPv4 >> allocations or assignments from the provider at >> the time of this assignment. >> 3. The customer must not have any direct assignments >> from ARIN at the time of this assignment. >> 4. The customer must not have more than a single >> IPv4 /32 from any other provider at the time of >> this assignment. >> 5. The customer must have IPv6 addresses with IPv6 >> connectivity to the ISP/LIR (must be dual-stacked). >> 6. The ISP/LIR must demonstrate that it already >> provides IPv6 addressing and connectivity to at >> least one existing customer for each /32 requested, >> up to 90% of their total customer base. >> 7. No organization shall receive more than a total >> of a /14 or equivalent under this section. >> >> (b) An ISP/LIR or End user organization may request a block >> no smaller than a /28 and no larger than a /23 per quarter >> to provide single IPv4 /32s to each physical server used >> to provide Internet reachable content. >> 1. Space issued under this provision is an assignment, >> not an allocation. An LIR may not distribute this >> space to their customers. >> 2. No server may recieve more than a single IPv4 /32 >> under this provision. >> 3. The server must have IPv6 addresses with IPv6 >> connectivity (must be dual-stacked). >> 4. The recieving organization must demonstrate that it >> already provides IPv6 addressing and connectivity >> to at least one existing server in addition to the >> server for which each /32 is requested, up to 100% >> of their total server base. (organizations which >> can show 100% dual stack are exempt from this >> requirement). >> 5. The recieving organization must IPv6 enable all of >> their content on the following schedule: >> >> + 25% of content IPv6 reachable within six >> months of receiving their first addresses >> under this policy >> + 50% of content IPv6 reachable within one year >> of receiving their first addresses under this >> policy >> + 75% of content IPv6 reachable within 18 months >> of receiving their first addresses under this >> policy >> + 90% of content IPv6 reachable within 24 months >> of receiving their first addresses under this >> policy >> >> 6. No organization shall receive more than a total of >> a /16 or equivalent under this section. >> >> (c) An ISP/LIR or End user organization may request a block no >> smaller than a /29 and no larger than a /25 per quarter for >> purposes relevant to their ability to deploy IPv6. >> 1. Space issued under this provision is an assignment, >> not an allocation. An LIR may not distribute this >> space to their customers. >> 2. Space issued under this provision must be used to >> provide the required public IPv4 address(es) for >> transitional technologies operated by the recipient >> organization. >> >> Specific examples of permitted uses are: >> a. Large scale or "Carrier Grade" NAT >> b. NAT-PT >> c. DS-LITE/B4/AFTeR >> d. IVI >> e. DNS64 or other transitional DNS enablers >> f. For other technologies of similar purpose >> and scope. >> >> 3. A /10 from the final /8 shall be reserved for issuance >> under this provision. In no case shall any addresses >> from this /10 be issued for any purpose outside >> of 4.10.4(c). >> >> (d) Applications which would qualify for IPv4 under section 4.4 of >> the NRPM (critical infrastructure) may qualify for IPv4 space >> under this policy if they meet the following criteria: >> 1. The critical infrastructure to be numbered must also >> have IPv6 addresses and must provide all services >> provided on IPv4 over IPv6 on the same time table. >> 2. Assignments under this provision shall be the >> smallest technically feasible size for the critical >> infrastructure in question. >> 3. The total space assigned under this provision shall not >> exceed the equivalent of a /14. >> >> (e) A content distribution network providing SSL terminations for >> SSL application or content acceleration may receive space >> under the following conditions: >> 1. No organization shall receive more than an >> aggregate /20 under this provision. >> 2. For each /32 issued under this provision, there >> must be at least 8 unique SSL named terminations >> converted to dual stack. (A unique named termination >> is one in which the certificate DistinguishedName >> and/or SubjectAltName is unique as well as the IP >> address terminating the connection). An organization >> which can show that they have dual stacked 100% of >> their SSL terminations shall be exempted from this >> requirement. >> 3. The total space issued under this provision shall >> not exceed an aggregate /11 or equivalent. >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Sun Sep 19 20:51:56 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 19 Sep 2010 17:51:56 -0700 Subject: [arin-ppml] Draft Policy 2010-13 Version 1.52 Message-ID: <5ABE0F86-5C02-4D3D-ACF5-7A791DFCAABF@delong.com> Below is the current state of draft policy 2010-13. I believe that the rationale begins to explain why the policy has grown. Yes, this policy is much more complex than the existing 4.10 or the original 2010-13. It seeks to address a much more complete set of issues which exist in a complex environment. Much effort has been made to simplify the policy as much as possible while retaining intent and meeting the needs of various ARIN stakeholder communities as fairly as possible under the circumstances. The reality is that runout is going to affect every single IP using organization. This policy seeks to spread that effect as evenly as possible in a manner proportionate to additional address space need. Comments and feedback are appreciated. I hope the policy can receive broad community support as I believe it is as fair and balanced an approach to runout as we can achieve. The rationale is still a work in progress and will likely still receive substantial edits. The policy is now frozen outside of minor editorial changes and changes to address staff and/or legal feedback. Please feel free to contact me on or off list with any questions or comments regarding this draft policy. Owen Draft Policy 2010-13: Permitted Uses of Space Reserved under NRPM 4.10 Proposal Originator: Owen DeLong Proposal Version: 1.52 Date: 5 September 2010 Proposal type: modify Policy term: permanent Policy statement: Remove section 4.1.8 (Unmet requests) from the NRPM. Replace the text of section 4.10 in its entirety (including the name) with: 4.10 IPv4 Transition Pool Post IANA Regular Pool Depletion When ARIN receives its /8 IPv4 allocation from IANA under the global policy titled "Global Policy for the Allocation of the Remaining IPv4 Address Space" ratified by ICANN Board on 6 March, 2009, that /8 will form a dedicated pool to facilitate IPv6 Deployment. Addresses returned to ARIN and not subject to a regional or global transfer policy will be reserved for utilization in the transition pool. Allocations and assignments from this block must be justified by IPv6 transition requirements. Examples of such needs include: + IPv4 addresses for key dual stack DNS servers + NAT-PT + IVI + NAT464 translators ARIN will use their discretion in determining whether a particular application meets the spirit of this policy. 4.10.1 Addressing Plan Any organization wishing to receive IPv4 addresses through this policy must submit a detailed addressing plan for any request that is made containing the following: (a) Their addressing needs over the entire reservation period and (b) Methods of meeting all requirements (requirements are explained in section 4.10.4.) over the entire reservation period. 4.10.2 Reservation System Initially, all space assigned or allocated under this policy will be reserved in advance for a maximum period of 36 months, requests for shorter reservations will be accepted. The total reservation size will be rounded up to a CIDR bit boundary. Each organization's reservation amount will be divided into quarterly allotments. Allotments will be rounded up to a CIDR bit boundary. The final quarterly allotment will contain only the remaining space from the full reservation. An organization may request one reservation under each provision listed in section 4.10.4. Once a reservation has been satisfied, another may be requested. 4.10.2.1 Reservation Requests Prior to Initial ARIN Free Pool Depletion Reservations will be accepted from the time that this policy is adopted until the day that ARIN can no longer fill regular requests from space allocated to ARIN by IANA. At that time, if necessary, all reservations will be reduced by an equal amount to allow them to fit within the total space available in the transition pool. No reservation will be reduced lower than the minimum quarterly allotment for it's category. Each organization may decide whether to adjust the reservation period or the allotment size (within the stated range) when reservations are reduced. Organizations must make this decision within 30 days of announcement and may not alter their choice once made. Any space added to the transition pool during this time will cause a final recalculation of reservation sizes. Once all necessary adjustments are made, all reservations are guaranteed and the first quarterly allotment is issued to each org. 4.10.2.2 Reservation Requests Post ARIN Free Pool Depletion Reservation requests received after ARIN free pool depletion as defined in 4.10.2.1 will not be guaranteed. If approved, such requests will be placed in a queue. As space becomes available in the transition pool it will be used to provide allotments to organizations with reservations in the queue on a first-approved first-served basis. Partially filled allotments will remain at the front of the queue. 4.10.2.3 Abandonment of Reservation Any organization may abandon their remaining reservation at any time by informing ARIN of their desire to do so. Upon abandonment, the remaining space in the reservation will be returned to the transition pool. 4.10.3 Quarterly Requirements Organizations with approved reservations and address plans are entitled to quarterly allotments. In order to receive each additional allotment, an organization must submit evidence of compliance with the following sub-sections: (a) The most recent 4.10 allotment is at least 80% utilized. (b) All prior 4.10 allotments within the same 4.10.4 category are at least 90% utilized. (c) All utilization is permitted under the 4.10.4 category for which it was initially requested. For purposes of this computation, space received under each provision shall be considered separately if an organization has received resources through multiple provisions. If an organization does not meet all obligations in any given quarter, that organization shall not receive that quarter's allotment and shall have their reservation reduced by one quarterly allotment. If an organization does not meet all obligations for three consecutive quarters, that organization forfeits the remainder of their reserved block. Utilization requirements (a) may be delayed at ARIN's discretion. If an organization is using space received under 4.10 in a manner contrary to 4.10, that organization forfeits their remaining reservation and may have their entire allocation or assignment revoked. All 4.10. space forfeited, revoked or otherwise reclaimed shall be returned to the ARIN transition pool. 4.10.4 Specific types of transitional uses have specific requirements: (a) An ISP/LIR may request a block no smaller than a /25 nor larger than a /18 per quarter to be used to provide single IPv4 /32s to their customers which could justify a /28 or more of IPv4 under ARIN policies in effect at the time of IANA depletion. 1. No customer site may receive more than a single IPv4 /32 per 1,000 Internet connected hosts upto 8 /32s. 2. The customer site must not have any IPv4 addresses not issued under this policy. 3. The customer site must use the /32 to provide IPv4 connectivity for hosts which have IPv6 addresses with IPv6 connectivity to the ISP/LIR. 4. The ISP/LIR must demonstrate that it already provides IPv6 addressing and connectivity to at least one additional existing customer site for each /32 requested, up to 90% of all customer sites served (across all customers). 5. An ISP/LIR customer which is not large enough to qualify under this provision and has no unassigned IPv4 addresses may receive an appropriate number of /32s from their upstream provider for reassignment to their customers under the terms of 4.10.4(a). 6. A customer site which terminates multiple connections from the same provider on separate routers may qualify for one /32 per unique router with a direct connection to the provider, up to a total of 8 /32s. 7. The total space issued to all organizations under this provision shall not exceed an aggregate /9 or equivalent per /8 placed into the transition pool. (b) An ISP/LIR or End user organization may request a block no smaller than a /28 and no larger than a /23 per quarter to provide single IPv4 /32s to each physical server used to provide Internet reachable content. 1. Space issued under this provision is an assignment, not an allocation. An LIR may not distribute this space to their customers. 2. No server may receive more than a single IPv4 /32 under this provision. 3. The server must have IPv6 addresses with IPv6 connectivity (must be dual-stacked). 4. The receiving organization must demonstrate that it already provides IPv6 addressing and connectivity to at least one additional existing server (organizations which can show 100% dual stack are exempt from this requirement). 5. The receiving organization must IPv6 enable all of their content on the following schedule: + 25% of content IPv6 reachable within six months of receiving their first addresses under this policy + 50% of content IPv6 reachable within one year of receiving their first addresses under this policy + 75% of content IPv6 reachable within 18 months of receiving their first addresses under this policy + 90% of content IPv6 reachable within 24 months of receiving their first addresses under this policy 6. A network providing SSL terminations for applications or content acceleration may receive a /32 for each distinguished name by following all requirements in this provision, substituting "distinguished name" for "server." 7. The total space issued to all organizations under this provision shall not exceed an aggregate /9 or equivalent per /8 placed into the transition pool. (c) An ISP/LIR or End user organization may request a block no smaller than a /29 and no larger than a /25 per quarter for purposes relevant to their ability to deploy IPv6. 1. Space issued under this provision is an assignment, not an allocation. An LIR may not distribute this space to their customers. 2. Space issued under this provision must be used to provide the required public IPv4 address(es) for transitional technologies operated by the recipient organization. Specific examples of permitted uses are: a. Large scale or "Carrier Grade" NAT b. NAT-PT c. DS-LITE/B4/AFTeR d. IVI e. DNS64 or other transitional DNS enablers f. Other technologies of similar purpose and scope. 3. A /10 from the final /8 shall be reserved for issuance under this provision. In no case shall any addresses from this /10 be issued for any purpose outside of 4.10.4(c). (d) Applications which would qualify for IPv4 under section 4.4 of the NRPM (critical infrastructure) may qualify for IPv4 space under this policy if they meet the following criteria: 1. The critical infrastructure to be numbered must also have IPv6 addresses and must provide all services provided on IPv4 over IPv6 on the same time table. 2. Assignments under this provision shall be the smallest technically feasible size for the critical infrastructure in question. 3. The total space assigned under this provision shall not exceed the equivalent of a /14. Rationale: The current terminology in section 4.10 is vague and could allow a variety of interpretations which could lead to allocations or assignments being made to ISPs intending to misuse the space for general deployment by using IPv6 overlay technologies as a "IPv6 deployments" requiring IPv4 space for transition. For example, the current policy could be interpreted to enable an ISP to require IPv4 addresses for all IPv6 customers to roll IPv6 out as 6rd to customers who would be otherwise unable to get IPv4 space. This is clearly outside of the original intent of the proposal which created 4.10 (6rd was not yet envisioned at the time that was written). This proposal seeks to clarify that intent and tighten up the requirements for organizations seeking to get space from this limited final resource so that it truly is available to facilitate transitional technologies. Additionally, there are a number of community segments that are not well served by the original intent of 4.10 and several community members requested a mechanism for providing a certain amount of certainty with regards to obtaining space at the end. While it would be impossible to guarantee organizations all the space they need as runout is upon us, this policy seeks to provide a way for organizations to sign up for and receive a reservation from the final space proportionate to their need. The policy also includes guidelines intended to ensure that this vital community resource is given only to organizations working towards a smooth transition to IPv6 to the benefit of the full community. In order to meet these needs, this policy has become very complex. It is an unfortunate artifact of the complex issue it seeks to address. A great deal of effort has been made to simplify the policy as much as possible, and, special thinks go out to several members of the community for their assistance in this matter. One provision in this draft policy calls for utilization criteria which may be waived by ARIN staff discretion. The intent of this clause is to allow staff to avoid penalizing an organization for successful address conservation efforts. Runout is upon us. IANA will run out of the IANA free pool and issue the last /8 this policy seeks to regulate before the next ARIN public policy meeting. If we are to make any attempt at fair distribution for the sake of IPv6 deployment, this is our final opportunity to do so outside of an emergency action by the ARIN board. Timetable for implementation: immediate For reference, here is the current text of 4.10 4.10 Dedicated IPv4 block to facilitate IPv6 Deployment When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous /10 IPv4 block will be set aside and dedicated to facilitate IPv6 deployment. Allocations and assignments from this block must be justified by immediate IPv6 deployment requirements. Examples of such needs include: IPv4 addresses for key dual stack DNS servers, and NAT-PT or NAT464 translators. ARIN staff will use their discretion when evaluating justifications. This block will be subject to a minimum size allocation of /28 and a maximum size allocation of /24. ARIN should use sparse allocation when possible within that /10 block. In order to receive an allocation or assignment under this policy: 1. the applicant may not have received resources under this policy in the preceding six months; 2. previous allocations/assignments under this policy must continue to meet the justification requirements of this policy; 3. previous allocations/assignments under this policy must meet the utilization requirements of end user assignments; 4. the applicant must demonstrate that no other allocations or assignments will meet this need; 5. on subsequent allocation under this policy, ARIN staff may require applicants to renumber out of previously allocated / assigned space under this policy in order to minimize non-contiguous allocations. From michel at arneill-py.sacramento.ca.us Sun Sep 19 22:32:18 2010 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Sun, 19 Sep 2010 19:32:18 -0700 Subject: [arin-ppml] Draft Policy 2010-13 Version 1.52 Message-ID: 3:170 An HTML attachment was scrubbed... URL: From michael.dillon at bt.com Mon Sep 20 05:02:14 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 20 Sep 2010 10:02:14 +0100 Subject: [arin-ppml] What is a "host"? In-Reply-To: <95E4C0A8-4A81-4D0B-8FA1-BB65AC0244E5@delong.com> References: <3026D718-E8C1-4549-9E85-FB9C2139FC68@tcb.net> <03aa01cb55d3$2b09bcf0$811d36d0$@com> <984E935A-E2BE-4D5D-B24E-A81CE9523373@delong.com> <0F29D1BA57992E4CAB5AD2C9AE7B42391CF4E005@EMV01-UKBR.domain1.systemhost.net> <95E4C0A8-4A81-4D0B-8FA1-BB65AC0244E5@delong.com> Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B423935E05450@EMV01-UKBR.domain1.systemhost.net> > If you have an interface that is speaking IPv6, it should count as one > host. > If you have 20 interfaces speaking IPv6, they should count as 20 hosts. > If you have 5 interfaces in a NIC-Team speaking IPv6, they should count > as one host. What is a NIC-Team and why do its interfaces not count as hosts? > Really, counting up the number of things that require an IPv6 link > local address is _NOT_ rocket science, nor is it technically complex. It is still not clear whether virtual interfaces on virtual machines such as XEN, VMWare, HyperV use a link-local address. Do they count or not? It is also not clear whether or not this might be an implementation detail, i.e. some implementations of virtualisation might use a link loca per virtual interface and others might not. For that matter, it may even be a configuration detail. But let's go back to square one. A single /64 subnet has the capacity to hold all the hosts that you or I might ever need, even if we expand to become a multinational business empire and implement virtual machines on our virtual machines. So why are we counting hosts? Shouldn't we just be counting subnets as the most finely grained measure that an RIR is interested in? --Michael Dillon From BillD at cait.wustl.edu Mon Sep 20 10:57:55 2010 From: BillD at cait.wustl.edu (Bill Darte) Date: Mon, 20 Sep 2010 09:57:55 -0500 Subject: [arin-ppml] Draft Policy 2010-10: Text Frozen for Atlanta Meeting Message-ID: Hello, Following is the text for Draft Policy 2010-10 Global Policy for IPv4 Allocations by the IANA Post Exhaustion which has been 'frozen' in accordance with the ARIN Policy Development Process (PDP). This freezing of text is important in order for each stakeholder to have time to review its common form and develop/share opinions prior to and at the following Public Policy Meeting. This final language has been edited from its original posting through several iterations based upon comments received by the authors from PPML, the Advisory Council of ARIN, private conversations and input from other RIRs. The language is posted here by consensus of the Advisory Council for your review. This Draft Policy of the Advisory Council will be presented at the Atlanta Public Policy Meeting by Martin Hannigan. All input is welcomed now and at the meeting. Bill Darte ARIN Advisory Council Primary Shepherd for Draft Policy 2010-10 Draft Policy 2010-10: Global Policy for IPv4 Allocations by the IANA Post Exhaustion Date: 18 September 2010 Policy statement: 1. Reclamation Pool Upon adoption of this IPv4 address policy by the ICANN Board of Directors, the IANA shall establish a Reclamation Pool to be utilized post RIR IPv4 exhaustion as defined in Section 4. The reclamation pool will initially contain any fragments that may be left over in IANA inventory. As soon as the first RIR exhausts its inventory of IP address space, this Reclamation Pool will be declared active. When the Reclamation Pool is declared active, the Global Policy for the Allocation of the Remaining IPv4 Address Space[3] and Policy for Allocation of IPv4 Blocks to Regional Internet Registries[4] will be formally deprecated. 2. Returning Address Space to the IANA The IANA will accept into the Reclamation Pool all eligible IPv4 address space that are offered for return. Eligible address space includes addresses that are not designated as "special use" by an IETF RFC or addresses allocated to RIR's unless they are being returned by the RIR that they were orignally allocated to. Legacy address holders may return address space directly to the IANA if they so choose. 3. Address Allocations from the Reclamation Pool by the IANA Allocations from the Reclamation Pool may begin once the pool is declared active. Addresses in the Reclamation Pool must be allocated on a CIDR boundary. Allocations from the Reclamation Pool are subject to a minimum allocation unit equal to the minimum allocation unit of all RIRs and a maximum allocation unit of one /8. The Reclamation Pool will be divided on CIDR boundaries and distributed evenly to all eligible RIRs once each quarter. Any remainder not evenly divisible by the number of eligible RIRs will remain in the Reclamation Pool until such time sufficient address returns allow another round of allocations. 4. RIR Eligibility for Receiving Allocations from the Reclamation Pool Upon the exhaustion of an RIR's free space pool and after receiving their final /8 from the IANA[3], an RIR will become eligible to request address space from the IANA Reclamation Pool when it publicly announces via its respective global announcements email list and by posting a notice on its website that it has exhausted its supply of IPv4 address space. Exhaustion is defined as an inventory of less than the equivalent of a single /8 and the inability to further assign address space to its customers in units equal to or shorter than the longest of any RIR's policy defined minimum allocation unit. Up to one /10 or equivalent of IPv4 address space specifically reserved for any special purpose by an RIR will not be counted against that RIR when determining eligibility unless that space was received from the IANA reclamation pool. Any RIR that is formed after the ICANN Board of Directors has ratified this policy is not eligible to utilize this policy to obtain IPv4 address space from the IANA. 5. Reporting Requirements The IANA shall publish on at least a weekly basis a report that is publicly available which at a minimum details all address space that has been received and that has been allocated. The IANA shall publish a Returned Address Space Report which indicates what resources were returned, by whom and when. The IANA shall publish an Allocations Report on at least a weekly basis which at a minimum indicates what IPv4 address space has been allocated, which RIR received the allocation and when. The IANA shall publish a public notice confirming RIR eligibility subsequent to Section 4. 6. No Transfer Rights Address space assigned from the Reclamation Pool may be transferred if there is either an ICANN Board ratified global policy or globally coordinated RIR policy specifically written to deal with transfers whether inter-RIR or from one entity to another. Transfers must meet the requirements of such a policy. In the absence of such a policy, no transfers of any kind related to address space allocated or assigned from the reclamation pool is allowed. 7. Definitions IANA - Internet Assigned Numbers Authority, or its successor ICANN - Internet Corporation for Assigned Names and Numbers, or its successor RIR - Regional Internet Registry as recognized by ICANN MOU - Memorandum of Understanding between ICANN and the RIRs IPv4 - Internet Protocol Version Four(4), the target protocol of this Global Policy Free Space Pool - IPv4 Addresses that are in inventory at any RIR, and/or the IANA 8. Contributors The following individuals donated their time, resources and effort to develop this proposal on behalf of the Internet Community: Steve Bertrand Chris Grundemann Martin Hannigan Aaron Hughes Louie Lee Matt Pounsett Jason Schiller 9. References 1. http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm Global Policy for the Allocation of the Remaining IPv4 Address Space, IANA, Retrieved 27 April 2010 2. http://aso.icann.org/documents/memorandum-of-understanding/index.html ICANN Address Supporting Organization (ASO) MoU , Retrieved 27 May 2010. 3. http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm Global Policy for the Allocation of the Remaining IPv4 Address Space 4. http://aso.icann.org/wp-content/uploads/2009/09/aso-001-2.pdf Policy for Allocation of IPv4 Blocks to Regional Internet Registries -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Mon Sep 20 11:38:49 2010 From: bill at herrin.us (William Herrin) Date: Mon, 20 Sep 2010 11:38:49 -0400 Subject: [arin-ppml] What is a "host"? In-Reply-To: <0F29D1BA57992E4CAB5AD2C9AE7B423935E05450@EMV01-UKBR.domain1.systemhost.net> References: <3026D718-E8C1-4549-9E85-FB9C2139FC68@tcb.net> <03aa01cb55d3$2b09bcf0$811d36d0$@com> <984E935A-E2BE-4D5D-B24E-A81CE9523373@delong.com> <0F29D1BA57992E4CAB5AD2C9AE7B42391CF4E005@EMV01-UKBR.domain1.systemhost.net> <95E4C0A8-4A81-4D0B-8FA1-BB65AC0244E5@delong.com> <0F29D1BA57992E4CAB5AD2C9AE7B423935E05450@EMV01-UKBR.domain1.systemhost.net> Message-ID: On Mon, Sep 20, 2010 at 5:02 AM, wrote: > It is still not clear whether virtual interfaces on virtual machines > such as XEN, VMWare, HyperV use a link-local address. Do they count or > not? It is also not clear whether or not this might be an implementation > detail, i.e. some implementations of virtualisation might use a link loca > per virtual interface and others might not. For that matter, it may even > be a configuration detail. > > But let's go back to square one. A single /64 subnet has the capacity to > hold all the hosts that you or I might ever need, even if we expand to > become a multinational business empire and implement virtual machines on > our virtual machines. > > So why are we counting hosts? Shouldn't we just be counting subnets as the > most finely grained measure that an RIR is interested in? Michael, If we're going to tally anything, counting the IPv6 subnets is a much better match to the technology than counting the IPv6 hosts. But, as many problems as that solves, it creates a whole "host" of new ones. Infrastructure providers tend to need a lot of subnets while hosting providers tend not to. If we went by straight subnet counts, we'd likely disadvantage the hosting providers. So, we really have to go back to basics if we want to do something sensible with v6 policy. There are two foundations for PI addresses: 1. You're multihomed with BGP and that requires BGPable address space for which there is no evident advantage (and clear disadvantages) to using a cutout from someone else's addresses. 2. You have a substantial enough system that renumbering to change your upstream provider is a more unreasonable burden than compelling everybody else to carry the route for your PI addresses. Start from those foundations and work forward. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From michael.dillon at bt.com Mon Sep 20 11:53:15 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 20 Sep 2010 16:53:15 +0100 Subject: [arin-ppml] What is a "host"? In-Reply-To: References: <3026D718-E8C1-4549-9E85-FB9C2139FC68@tcb.net> <03aa01cb55d3$2b09bcf0$811d36d0$@com> <984E935A-E2BE-4D5D-B24E-A81CE9523373@delong.com> <0F29D1BA57992E4CAB5AD2C9AE7B42391CF4E005@EMV01-UKBR.domain1.systemhost.net> <95E4C0A8-4A81-4D0B-8FA1-BB65AC0244E5@delong.com> <0F29D1BA57992E4CAB5AD2C9AE7B423935E05450@EMV01-UKBR.domain1.systemhost.net> Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B423935E057B2@EMV01-UKBR.domain1.systemhost.net> > So, we really have to go back to basics if we want to do something > sensible with v6 policy. There are two foundations for PI addresses: Then count interfaces. In IPv6, addresses are assigned to interfaces, and networks are composed of subnets, which contain a bunch of interfaces. Nobody is going to walk around and count 1000 interfaces anyway. They are going to estimate the number based on some other data such as switch ports installed and VMs per server or VMs in the customer database. > 2. You have a substantial enough system that renumbering to change > your upstream provider is a more unreasonable burden than compelling > everybody else to carry the route for your PI addresses. > > Start from those foundations and work forward. Given that we are talking about IPv6 renumbering, not IPv4 renumbering, subnets still seems like a good measure. In IPv6, the subnets are unchanged and you just change the network prefix handed out by SLAAC or DHCPv6. --Michael Dillon From leo.vegoda at icann.org Mon Sep 20 12:13:12 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 20 Sep 2010 09:13:12 -0700 Subject: [arin-ppml] 2010-8: Rework of IPv6 assignment criteria In-Reply-To: <4C9552B9.4000503@umn.edu> References: <4C8F29DA.8020003@umn.edu> <4C9552B9.4000503@umn.edu> Message-ID: <10C69619-8742-4E5B-A527-D6A010BE3399@icann.org> On 18 Sep 2010, at 5:00, David Farmer wrote: [...] > Furthermore, very large hierarchical end-user networks, especially for a > large multinational corporation, are not precluded from considering > themselves as an ISP or LIR, and then starting with a /32 and being able > to avail themselves of HD-Ratio. That might be more appropriate anyway, > the networks for large multinational corporation with many independent > business units, probably have much more in common with ISPs then the > majority of other end-user networks. I think this would resolve the problem for larger, more complex end user networks. Leo From owen at delong.com Mon Sep 20 13:47:11 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 20 Sep 2010 10:47:11 -0700 Subject: [arin-ppml] 2010-8: Rework of IPv6 assignment criteria In-Reply-To: <10C69619-8742-4E5B-A527-D6A010BE3399@icann.org> References: <4C8F29DA.8020003@umn.edu> <4C9552B9.4000503@umn.edu> <10C69619-8742-4E5B-A527-D6A010BE3399@icann.org> Message-ID: <91294978-61DD-42C3-AF15-08933474AD9E@delong.com> On Sep 20, 2010, at 9:13 AM, Leo Vegoda wrote: > On 18 Sep 2010, at 5:00, David Farmer wrote: > > [...] > >> Furthermore, very large hierarchical end-user networks, especially for a >> large multinational corporation, are not precluded from considering >> themselves as an ISP or LIR, and then starting with a /32 and being able >> to avail themselves of HD-Ratio. That might be more appropriate anyway, >> the networks for large multinational corporation with many independent >> business units, probably have much more in common with ISPs then the >> majority of other end-user networks. > > I think this would resolve the problem for larger, more complex end user networks. > > Leo I think the simpler (and much cheaper for the organization) approach would be to realize that the "Large Complex" networks are almost never implemented in a single building. End user networks within a given structure tend to have very few layers, often consisting of: workgroup->floor->datacenter->Building exit Rarely does it get to more layers than that and moving prefixes around within the structure is relatively free form. There is usually very little loss of prefix space due to aggregation at any of those levels because within a building, aggregation is usually regarded as meaningless. Since EACH structure gets at least a /48 and you are guaranteed a certain amount of headroom in the number of /48s you get if you have more than a single building, I simply don't see where this could become an issue. Leo, can you provide a concrete counter-example? Owen From bill at herrin.us Mon Sep 20 13:49:34 2010 From: bill at herrin.us (William Herrin) Date: Mon, 20 Sep 2010 13:49:34 -0400 Subject: [arin-ppml] What is a "host"? In-Reply-To: <0F29D1BA57992E4CAB5AD2C9AE7B423935E057B2@EMV01-UKBR.domain1.systemhost.net> References: <3026D718-E8C1-4549-9E85-FB9C2139FC68@tcb.net> <03aa01cb55d3$2b09bcf0$811d36d0$@com> <984E935A-E2BE-4D5D-B24E-A81CE9523373@delong.com> <0F29D1BA57992E4CAB5AD2C9AE7B42391CF4E005@EMV01-UKBR.domain1.systemhost.net> <95E4C0A8-4A81-4D0B-8FA1-BB65AC0244E5@delong.com> <0F29D1BA57992E4CAB5AD2C9AE7B423935E05450@EMV01-UKBR.domain1.systemhost.net> <0F29D1BA57992E4CAB5AD2C9AE7B423935E057B2@EMV01-UKBR.domain1.systemhost.net> Message-ID: On Mon, Sep 20, 2010 at 11:53 AM, wrote: >> So, we really have to go back to basics if we want to do something >> sensible with v6 policy. There are two foundations for PI addresses: > > Then count interfaces. > In IPv6, addresses are assigned to interfaces, and networks are composed > of subnets, which contain a bunch of interfaces. Six of one, half a dozen of the other. Go back to basics. The foundations are about dollar cost. In fact, they're about two specific dollar costs. The worldwide systemic cost of introducing an IPv6 route into the BGP table is somewhere between $10k and $15k per year by now. (http://bill.herrin.us/network/bgpcost.html) Renumbering has a cost as well, based on the manpower spent changing configurations, debugging the changes that don't work, and the cost of the inevitable service disruptions during the renumbering process. In the multihoming case, the BGP cost is the same either way, so the renumbering cost is always higher, except to whatever degree folks would decide to add multihoming to meet policy versus multihoming to achieve required system resilience. In the singlehomed case, the questions are: a. How much more than the BGP cost should the renumbering cost be before it's reasonable to allow the BGP cost? b. What metric do you use to assess the renumbering cost? > Given that we are talking about IPv6 renumbering, not IPv4 renumbering, > subnets still seems like a good measure. In IPv6, the subnets are unchanged > and you just change the network prefix handed out by SLAAC or DHCPv6. Respectfully, the assumption that IPv6 renumbering will prove meaningfully less costly than IPv4 renumbering is still unfounded. Wait for it to play out in large, real-world deployments before building this assumption into policy. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From farmer at umn.edu Mon Sep 20 13:59:02 2010 From: farmer at umn.edu (David Farmer) Date: Mon, 20 Sep 2010 12:59:02 -0500 Subject: [arin-ppml] What is a "host"? In-Reply-To: <0F29D1BA57992E4CAB5AD2C9AE7B423935E057B2@EMV01-UKBR.domain1.systemhost.net> References: <3026D718-E8C1-4549-9E85-FB9C2139FC68@tcb.net> <03aa01cb55d3$2b09bcf0$811d36d0$@com> <984E935A-E2BE-4D5D-B24E-A81CE9523373@delong.com> <0F29D1BA57992E4CAB5AD2C9AE7B42391CF4E005@EMV01-UKBR.domain1.systemhost.net> <95E4C0A8-4A81-4D0B-8FA1-BB65AC0244E5@delong.com> <0F29D1BA57992E4CAB5AD2C9AE7B423935E05450@EMV01-UKBR.domain1.systemhost.net> <0F29D1BA57992E4CAB5AD2C9AE7B423935E057B2@EMV01-UKBR.domain1.systemhost.net> Message-ID: <4C97A0E6.1090800@umn.edu> On 9/20/10 10:53 CDT, michael.dillon at bt.com wrote: >> So, we really have to go back to basics if we want to do something >> sensible with v6 policy. There are two foundations for PI addresses: > > Then count interfaces. > In IPv6, addresses are assigned to interfaces, and networks are composed > of subnets, which contain a bunch of interfaces. > > Nobody is going to walk around and count 1000 interfaces anyway. They are > going to estimate the number based on some other data such as switch ports > installed and VMs per server or VMs in the customer database. Isn't that what mostly happens today regarding these requirements in IPv4 today? >> 2. You have a substantial enough system that renumbering to change >> your upstream provider is a more unreasonable burden than compelling >> everybody else to carry the route for your PI addresses. >> >> Start from those foundations and work forward. > > Given that we are talking about IPv6 renumbering, not IPv4 renumbering, > subnets still seems like a good measure. In IPv6, the subnets are unchanged > and you just change the network prefix handed out by SLAAC or DHCPv6. In theory renumbering in IPv6 is easier than in IPv4, but in practice, while it is easier, it is not that significantly easier. Especially, when compared to renumbering IPv4 with DHCP, DNS is the biggest hassle in both cases. This might have been different if we were able to figure out A6 records, or something like them. I would like to see a subnet based definition for the second of the two foundations that Bill mentions above. However, I have not seen anyone mention a number, or any rationale for picking a number, that has any kind of consensus behind it. Also, a subnet count is still essentially an arbitrary number, yes it is a more meaningful number in IPv6 than host count, but I don't believe it will be any less arbitrary. While I dislike using a host count for IPv6, as I stated in my email on Friday, I believe maintaining a host count based on current IPv4 policy is necessary for the time being, at least until a reasonable time after IPv4 run-out is completed. If we can come to some kind of consensus on a subnet count I would be happy to add that into the policy as a fifth clause in section 6.5.8.1 Initial Assignment Criteria. It will probably be after the up coming meeting, as I doubt we can come to a consensus in the next day or two, in order get it into the text prior to the 10 day freeze before the meeting. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From gary.buhrmaster at gmail.com Mon Sep 20 14:08:36 2010 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Mon, 20 Sep 2010 18:08:36 +0000 Subject: [arin-ppml] 2010-8: Rework of IPv6 assignment criteria In-Reply-To: <4C9552B9.4000503@umn.edu> References: <4C8F29DA.8020003@umn.edu> <4C9552B9.4000503@umn.edu> Message-ID: On Sun, Sep 19, 2010 at 00:00, David Farmer wrote: .... > Furthermore, very large hierarchical end-user networks, especially for a > large multinational corporation, are not precluded from considering > themselves as an ISP or LIR, and then starting with a /32 and being able to > avail themselves of HD-Ratio. ?That might be more appropriate anyway, the > networks for large multinational corporation with many independent business > units, probably have much more in common with ISPs then the majority of > other end-user networks. I believe for many "large" end-users, this is the most logical approach. The posture child in a previous e-mail thread was HP. While I have no idea how HP networking operates internally, my first thought is that it is likely they are more like an ISP/LIR in that they provide service to their BU's/departments/whatevers and delegate address ranges to those groups for their uses. I would like to be sure that ARIN policy make it easy for such "end-users" to consider themselves ISP/LIRs (/32) where appropriate and justified. Gary From terry.l.davis at boeing.com Mon Sep 20 13:59:23 2010 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Mon, 20 Sep 2010 10:59:23 -0700 Subject: [arin-ppml] 2010-8: Rework of IPv6 assignment criteria In-Reply-To: <10C69619-8742-4E5B-A527-D6A010BE3399@icann.org> References: <4C8F29DA.8020003@umn.edu><4C9552B9.4000503@umn.edu> <10C69619-8742-4E5B-A527-D6A010BE3399@icann.org> Message-ID: <0267B5481DCC474D8088BF4A25C7F1DF5517F26CE6@XCH-NW-05V.nw.nos.boeing.com> All As you think about this, don't forget truly global international infrastructures. The International Civil Aviation Organization has published the requirement for new (Next generation) Air Traffic Management systems to utilize IPv6 addressing. Currently they provide OSI Air Traffic Network addresses for all existing commercial and civil aviation globally to "all" aircraft owners/operators. They likely will be looking for a single global PI IPv6 allocation for this new IPv6 based Air Traffic Network infrastructure soon. Take care Terry PS: Also don't forget that other folks like international non-profit organizations, international trade organizations, multi-entity national infrastructures (rail, grids), and others will likely also want IPv6 PI spaces too. > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Leo Vegoda > Sent: Monday, September 20, 2010 9:13 AM > To: David Farmer > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] 2010-8: Rework of IPv6 assignment criteria > > On 18 Sep 2010, at 5:00, David Farmer wrote: > > [...] > > > Furthermore, very large hierarchical end-user networks, > especially for a > > large multinational corporation, are not precluded from considering > > themselves as an ISP or LIR, and then starting with a /32 > and being able > > to avail themselves of HD-Ratio. That might be more > appropriate anyway, > > the networks for large multinational corporation with many > independent > > business units, probably have much more in common with ISPs > then the > > majority of other end-user networks. > > I think this would resolve the problem for larger, more > complex end user networks. > > Leo > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From michael.dillon at bt.com Mon Sep 20 16:24:26 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 20 Sep 2010 21:24:26 +0100 Subject: [arin-ppml] What is a "host"? In-Reply-To: References: <3026D718-E8C1-4549-9E85-FB9C2139FC68@tcb.net> <03aa01cb55d3$2b09bcf0$811d36d0$@com> <984E935A-E2BE-4D5D-B24E-A81CE9523373@delong.com> <0F29D1BA57992E4CAB5AD2C9AE7B42391CF4E005@EMV01-UKBR.domain1.systemhost.net> <95E4C0A8-4A81-4D0B-8FA1-BB65AC0244E5@delong.com> <0F29D1BA57992E4CAB5AD2C9AE7B423935E05450@EMV01-UKBR.domain1.systemhost.net> <0F29D1BA57992E4CAB5AD2C9AE7B423935E057B2@EMV01-UKBR.domain1.systemhost.net> Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B423935E05857@EMV01-UKBR.domain1.systemhost.net> > The worldwide systemic cost of introducing an IPv6 route into the BGP > table is somewhere between $10k and $15k per year by now. > (http://bill.herrin.us/network/bgpcost.html) Then on that basis, cut out the clause about 1000 hosts. That would make a lot more sense than trying to include complicated technical terminology into ARIN policy. > Respectfully, the assumption that IPv6 renumbering will prove > meaningfully less costly than IPv4 renumbering is still unfounded. > Wait for it to play out in large, real-world deployments before > building this assumption into policy. Has anyone done an in-depth analysis of this? There are many organizations that have been running IPv6 at scale for many years now, and most of them do have experience of renumbering. We need more facts and less guesswork. --Michael Dillon From michael.dillon at bt.com Mon Sep 20 16:27:54 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 20 Sep 2010 21:27:54 +0100 Subject: [arin-ppml] 2010-8: Rework of IPv6 assignment criteria In-Reply-To: <0267B5481DCC474D8088BF4A25C7F1DF5517F26CE6@XCH-NW-05V.nw.nos.boeing.com> References: <4C8F29DA.8020003@umn.edu><4C9552B9.4000503@umn.edu> <10C69619-8742-4E5B-A527-D6A010BE3399@icann.org> <0267B5481DCC474D8088BF4A25C7F1DF5517F26CE6@XCH-NW-05V.nw.nos.boeing.com> Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B423935E0585B@EMV01-UKBR.domain1.systemhost.net> > As you think about this, don't forget truly global international > infrastructures. The International Civil Aviation Organization has > published the requirement for new (Next generation) Air Traffic > Management systems to utilize IPv6 addressing. Currently they provide > OSI Air Traffic Network addresses for all existing commercial and civil > aviation globally to "all" aircraft owners/operators. > > They likely will be looking for a single global PI IPv6 allocation for > this new IPv6 based Air Traffic Network infrastructure soon. That is IANA's problem, not ours. > PS: Also don't forget that other folks like international non-profit > organizations, international trade organizations, multi-entity national > infrastructures (rail, grids), and others will likely also want IPv6 PI > spaces too. These are all rather smaller than ICAO and most of them can simply go to the RIR in their head office region. We don't usually treat international networks any different from single-country networks. --Michael Dillon From leo.vegoda at icann.org Mon Sep 20 16:39:07 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 20 Sep 2010 13:39:07 -0700 Subject: [arin-ppml] 2010-8: Rework of IPv6 assignment criteria In-Reply-To: <0F29D1BA57992E4CAB5AD2C9AE7B423935E0585B@EMV01-UKBR.domain1.systemhost.net> References: <4C8F29DA.8020003@umn.edu><4C9552B9.4000503@umn.edu> <10C69619-8742-4E5B-A527-D6A010BE3399@icann.org> <0267B5481DCC474D8088BF4A25C7F1DF5517F26CE6@XCH-NW-05V.nw.nos.boeing.com> <0F29D1BA57992E4CAB5AD2C9AE7B423935E0585B@EMV01-UKBR.domain1.systemhost.net> Message-ID: On 20 Sep 2010, at 1:27, wrote: > >> As you think about this, don't forget truly global international >> infrastructures. The International Civil Aviation Organization has >> published the requirement for new (Next generation) Air Traffic >> Management systems to utilize IPv6 addressing. Currently they provide >> OSI Air Traffic Network addresses for all existing commercial and civil >> aviation globally to "all" aircraft owners/operators. >> >> They likely will be looking for a single global PI IPv6 allocation for >> this new IPv6 based Air Traffic Network infrastructure soon. > > That is IANA's problem, not ours. While the RIR communities develop the policies that allow registrations in the IPv6 Global Unicast Address Assignments registry, you might want to reconsider that. Regards, Leo From leo.vegoda at icann.org Mon Sep 20 16:43:27 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 20 Sep 2010 13:43:27 -0700 Subject: [arin-ppml] 2010-8: Rework of IPv6 assignment criteria In-Reply-To: <91294978-61DD-42C3-AF15-08933474AD9E@delong.com> References: <4C8F29DA.8020003@umn.edu> <4C9552B9.4000503@umn.edu> <10C69619-8742-4E5B-A527-D6A010BE3399@icann.org> <91294978-61DD-42C3-AF15-08933474AD9E@delong.com> Message-ID: <6B6FF1EB-019A-454F-BD66-115B48AA9C8C@icann.org> On 20 Sep 2010, at 10:47, Owen DeLong wrote: [...] > I think the simpler (and much cheaper for the organization) approach > would be to realize that the "Large Complex" networks are almost never > implemented in a single building. I didn't realise that the proposal was for the organization to receive a separate PI assignment for each building or campus in their network. I had thought the proposal would allow an organization to receive a single (shortish) prefix to be used by multiple campus networks, data centers etc... Regards, Leo From stephen at sprunk.org Mon Sep 20 16:53:51 2010 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 20 Sep 2010 15:53:51 -0500 Subject: [arin-ppml] 2010-8: Rework of IPv6 assignment criteria In-Reply-To: <0267B5481DCC474D8088BF4A25C7F1DF5517F26CE6@XCH-NW-05V.nw.nos.boeing.com> References: <4C8F29DA.8020003@umn.edu><4C9552B9.4000503@umn.edu> <10C69619-8742-4E5B-A527-D6A010BE3399@icann.org> <0267B5481DCC474D8088BF4A25C7F1DF5517F26CE6@XCH-NW-05V.nw.nos.boeing.com> Message-ID: <4C97C9DF.20909@sprunk.org> On 20 Sep 2010 12:59, Davis, Terry L wrote: > As you think about this, don't forget truly global international infrastructures. There is no "global" infrastructure; all infrastructure is located in _some_ region(s). Multi-region networks can either obtain a prefix from one RIR and use it everywhere (if that RIR's policies allow), or they can obtain a separate prefix from each RIR for use in that region. This is not complicated. > The International Civil Aviation Organization has published the requirement for new (Next generation) Air Traffic Management systems to utilize IPv6 addressing. Currently they provide OSI Air Traffic Network addresses for all existing commercial and civil aviation globally to "all" aircraft owners/operators. > > They likely will be looking for a single global PI IPv6 allocation for this new IPv6 based Air Traffic Network infrastructure soon. And, if they can find a RIR that will give them one, more power to them. However, unless they're going to act as the sole LIR/ISP for every aviation-related network in the world, including connectivity to the public Internet, that doesn't seem like a good idea. I find it much more sensible for each member to get its own PI prefix, which can be advertised both into the ICAO network and the public Internet. > PS: Also don't forget that other folks like international non-profit organizations, international trade organizations, multi-entity national infrastructures (rail, grids), and others will likely also want IPv6 PI spaces too. Same answer. Merely operating across country or continental borders does not exempt one from the RIR system; there are hundreds if not thousands of examples of multinational corporations, and the RIR system works just fine. I see no reason why non-profits, trade organizations, infrastructure operators, etc. should be exempt when, as far as the network is concerned, they are no different. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3646 bytes Desc: S/MIME Cryptographic Signature URL: From dwcarder at wisc.edu Mon Sep 20 16:38:41 2010 From: dwcarder at wisc.edu (Dale W. Carder) Date: Mon, 20 Sep 2010 15:38:41 -0500 Subject: [arin-ppml] What is a "host"? In-Reply-To: <0F29D1BA57992E4CAB5AD2C9AE7B423935E05857@EMV01-UKBR.domain1.systemhost.net> References: <03aa01cb55d3$2b09bcf0$811d36d0$@com> <984E935A-E2BE-4D5D-B24E-A81CE9523373@delong.com> <0F29D1BA57992E4CAB5AD2C9AE7B42391CF4E005@EMV01-UKBR.domain1.systemhost.net> <95E4C0A8-4A81-4D0B-8FA1-BB65AC0244E5@delong.com> <0F29D1BA57992E4CAB5AD2C9AE7B423935E05450@EMV01-UKBR.domain1.systemhost.net> <0F29D1BA57992E4CAB5AD2C9AE7B423935E057B2@EMV01-UKBR.domain1.systemhost.net> <0F29D1BA57992E4CAB5AD2C9AE7B423935E05857@EMV01-UKBR.domain1.systemhost.net> Message-ID: <20100920203841.GA11252@ricotta.doit.wisc.edu> Thus spake michael.dillon at bt.com (michael.dillon at bt.com) on Mon, Sep 20, 2010 at 09:24:26PM +0100: > > > Respectfully, the assumption that IPv6 renumbering will prove > > meaningfully less costly than IPv4 renumbering is still unfounded. I certainly agree. > > Wait for it to play out in large, real-world deployments before > > building this assumption into policy. > > Has anyone done an in-depth analysis of this? There are many organizations > that have been running IPv6 at scale for many years now, and most of them > do have experience of renumbering. We need more facts and less guesswork. http://tools.ietf.org/html/rfc5887 In my experience renumbering from a /48 we had for testing into a /32, I didn't find anything "fixed" by ipv6. Dale From farmer at umn.edu Mon Sep 20 20:01:48 2010 From: farmer at umn.edu (David Farmer) Date: Mon, 20 Sep 2010 19:01:48 -0500 Subject: [arin-ppml] 2010-8: Rework of IPv6 assignment criteria In-Reply-To: <0267B5481DCC474D8088BF4A25C7F1DF5517F26CE6@XCH-NW-05V.nw.nos.boeing.com> References: <4C8F29DA.8020003@umn.edu><4C9552B9.4000503@umn.edu> <10C69619-8742-4E5B-A527-D6A010BE3399@icann.org> <0267B5481DCC474D8088BF4A25C7F1DF5517F26CE6@XCH-NW-05V.nw.nos.boeing.com> Message-ID: <4C97F5EC.6020903@umn.edu> On 9/20/10 12:59 CDT, Davis, Terry L wrote: > All > > As you think about this, don't forget truly global international infrastructures. The International Civil Aviation Organization has published the requirement for new (Next generation) Air Traffic Management systems to utilize IPv6 addressing. Currently they provide OSI Air Traffic Network addresses for all existing commercial and civil aviation globally to "all" aircraft owners/operators. > > They likely will be looking for a single global PI IPv6 allocation for this new IPv6 based Air Traffic Network infrastructure soon. The specific example of an ICAO Global Air Traffic Control Network, while very important, I believe is out of scope for draft policy 2010-8. This draft policy is intended for assignments directly to end-users networks from ARIN. By definition, an ICAO Global Air Traffic Control Network should not be thought of as a network for the use of a single end-user organization. While I think such a network is very important and should be able to get an IPv6 allocation and make assignments to the users of the network, I believe that is out of scope for this policy. If we bracket the issue of a single global prefix for a moment, I believe within the ARIN region that 6.5.1.3. Criteria for initial allocation to other LIRs would cover such a network. As for a single global prefix, I can see an argument for that, especially if each aircraft were given a globally unique prefix within a larger global prefix. However, I'm not completely convinced a single global prefix is justified. There may be other cases that justify global prefix, or at least claim to. I think this is a good area for future discussion, probably involving global policy across all the RIRs, the NRO, and maybe even ICANN. It might be useful for the RIR policy community to start thinking about what criteria would justify such a global prefix being set aside, the process for making such a determination, and how global prefixes should be coordinated, either by the RIRs or another standards body. As more and more of what what was considered separate areas of technology start to utilize IP for the communication component within their technology, it will be necessary for the Internet standards and policy communities and the standards and policy communities that exist for these originally separate technologies to work together. Compromise will be necessary, probably on both sides, but for sure at least on one side or the other. Neither side should just assume that the way things have been done with previous technologies is the way things should move forward into the future. > Take care > Terry > > PS: Also don't forget that other folks like international non-profit organizations, international trade organizations, multi-entity national infrastructures (rail, grids), and others will likely also want IPv6 PI spaces too. I think Internet connectivity for international corporations, for-profit, non-profit, governments or NGOs, are reasonably well covered by the current RIR system. I think the issue of Global critical command and control networks, like the Air Traffic Control Network should be discussed further, but we should automatically assume they can't be handled within the current RIR system. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From bill at herrin.us Mon Sep 20 20:01:57 2010 From: bill at herrin.us (William Herrin) Date: Mon, 20 Sep 2010 20:01:57 -0400 Subject: [arin-ppml] 2010-8: Rework of IPv6 assignment criteria In-Reply-To: <4C9552B9.4000503@umn.edu> References: <4C8F29DA.8020003@umn.edu> <4C9552B9.4000503@umn.edu> Message-ID: On Sat, Sep 18, 2010 at 8:00 PM, David Farmer wrote: >> Presumably, the reason for the difference is not that end user >> organizations are not capable of understanding the HD-ratio concept. And >> anyway, if it is difficult to understand, ARIN can be asked to produce >> explanatory materials. > > I want to refer people to RFC 3194: "The Host-Density Ratio for Address > Assignment Efficiency: An update on the H ratio" and section 6.7 of the > NRPM. > > https://www.arin.net/policy/nrpm.html#six7 > > Actually, while I believe many people do not understand HD-Ratio, especially > end-users, that isn't the only issue. if it were, then "explanatory > materials" could maybe solve the problem. RFC 3194 basically says this: We threw some formulas around and when we tried "log(addresses in use)/log(total address space) " it seemed to produce some consistent results for "too dense" across more than one historical addressing scheme. We found that: log(addresses in use)/log(total address space) < 0.80 works reasonably well and log(addresses in use)/log(total address space) > 0.87 doesn't work at all. In terms of addressing policy, it implies: get the next address allocation when your HD Ratio approaches 0.80. The basis for these numbers does not appear to be especially well sourced. Only three addressing systems were evaluated: two telephone numbering schemes and DECnet. It is, however, a testable prediction, the stuff any science is based on. RFC 3194 predicts that we can successfully employ no more than 214M IPv4 unicast addresses on the IPv4 Internet, or about 5.7% of the address space. Finding numbers on actual IPv4 address utilization proved difficult. I did find some numbers from CAIDA. They weren't quite on point, but they suggested that current utilization stands around 11%. If correct then the HD Ratio is disproven as a metric for assessing address utilization as 11% is far greater than the predicted maximum 5.7% and we're still functioning without excessive pain. As I said, those numbers weren't entirely on point so I can't use them to say they absolutely disprove RFC 3194. It does, however, make 3194's claims more dubious. The ARIN NRPM then takes this relatively straightforward theory and does something incomprehensible with it. It talks about "efficiency level is between 20% to 50% for most ISPs and LIRs when based on a 0.94 HD Ratio." And then it talks about /56 counts. But the theory behind HD Ratio is based on addresses deployed, not subnetworks. And it predicts a much lower HD ratio. And percentages of some HD ratio don't even make sense in context; you're supposed to use the ratio directly; the calculation replaces percentages. So, our current IPv6 addressing policy starts with an unproven and dubious theory that was then altered in arbitrary ways that totally removed it from any scientific basis. Such is our current basis for what's supposed to be reasonable IPv6 addressing policy. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From marty at akamai.com Tue Sep 14 01:06:01 2010 From: marty at akamai.com (Hannigan, Martin) Date: Tue, 14 Sep 2010 01:06:01 -0400 Subject: [arin-ppml] Suggested updates to Draft Policy 2010-10 (Global Message-ID: <20100921044020.231B612B4903@sa.esc7.net> An HTML attachment was scrubbed... URL: From marty at akamai.com Tue Sep 14 01:06:01 2010 From: marty at akamai.com (Hannigan, Martin) Date: Tue, 14 Sep 2010 01:06:01 -0400 Subject: [arin-ppml] Suggested updates to Draft Policy 2010-10 (Global Message-ID: <20100921044020.1D69D12B4901@sa.esc7.net> An HTML attachment was scrubbed... URL: From marty at akamai.com Tue Sep 14 01:06:01 2010 From: marty at akamai.com (Hannigan, Martin) Date: Tue, 14 Sep 2010 01:06:01 -0400 Subject: [arin-ppml] Suggested updates to Draft Policy 2010-10 (Global Message-ID: <20100921043932.ED7F412B48E9@sa.esc7.net> An HTML attachment was scrubbed... URL: From farmer at umn.edu Tue Sep 14 03:52:58 2010 From: farmer at umn.edu (David Farmer) Date: Tue, 14 Sep 2010 02:52:58 -0500 Subject: [arin-ppml] 2010-8: Rework of IPv6 assignment criteria Message-ID: <20100921044351.7317912B4829@sa.esc7.net> An HTML attachment was scrubbed... URL: From michael.dillon at bt.com Tue Sep 21 06:12:53 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 21 Sep 2010 11:12:53 +0100 Subject: [arin-ppml] 2010-8: Rework of IPv6 assignment criteria In-Reply-To: References: <4C8F29DA.8020003@umn.edu><4C9552B9.4000503@umn.edu> <10C69619-8742-4E5B-A527-D6A010BE3399@icann.org> <0267B5481DCC474D8088BF4A25C7F1DF5517F26CE6@XCH-NW-05V.nw.nos.boeing.com> <0F29D1BA57992E4CAB5AD2C9AE7B423935E0585B@EMV01-UKBR.domain1.systemhost.net> Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B423935E05A7B@EMV01-UKBR.domain1.systemhost.net> > >> They likely will be looking for a single global PI IPv6 allocation > for > >> this new IPv6 based Air Traffic Network infrastructure soon. > > > > That is IANA's problem, not ours. > > While the RIR communities develop the policies that allow registrations > in the IPv6 Global Unicast Address Assignments registry, you might want > to reconsider that. After some research I learned that the ICAO is headquartered in Montr?al and not Geneva as I had assumed. But even so, there is every likelihood that this will simply calculate some large size block based on requirements and it will fit in with the existing ARIN policy for ISPs. We will just give them a /16 or /20 or whatever, and be done with it. So far, there are no hard facts to indicate that this is anything out of the ordinary except possibly for size. And if they decide to allocate a /48 to every airport and a /64 to every aircraft out of some number of footprints (100? 200?) covering the globe, this might be a lot less than people think. Perhaps someone could invite the ICAO to explain their plans at a NANOG meeting to give us some visibility of their thinking and to give them the opportunity to get some free consultancy in the corridors of the meeting. Seems to me that ARIN's outreach programme is relevant as well, although it is a bit short notice to do something at this year's assembly (oct 8th). By the way if you search the ICAO site, they have a draft IPv6 addressing plan explqaining how to carve up ground site /48s as well as airborne site /48s There is also a statement that they will ask member states to acquire IPv6 address blocks from their local RIR for ground sites and the ICAO will only apply for a block to cover the airborne sites. There are currently about 500,000 aircraft worldwide including helicopters which would require eight /32s to give each one a /48. That is a /29. Round it up to a nibble boundary and you get a /28 which is the same kind of allocation the medium large ISPs are getting. There is really no problem here. --Michael Dillon From BillD at cait.wustl.edu Tue Sep 21 06:30:04 2010 From: BillD at cait.wustl.edu (Bill Darte) Date: Tue, 21 Sep 2010 05:30:04 -0500 Subject: [arin-ppml] Suggested updates to Draft Policy 2010-10 (Global References: <20100921043932.ED7F412B48E9@sa.esc7.net> Message-ID: Thanks Marty, But the text you cite below as part of Section 3 was changed (as you know) by the AC to the following: 3. Address Allocations from the Reclamation Pool by the IANA Allocations from the Reclamation Pool may begin once the pool is declared active. Addresses in the Reclamation Pool must be allocated on a CIDR boundary. Allocations from the Reclamation Pool are subject to a minimum allocation unit equal to the minimum allocation unit of all RIRs and a maximum allocation unit of one /8. The Reclamation Pool will be divided on CIDR boundaries and distributed evenly to all eligible RIRs once each quarter. Any remainder not evenly divisible by the number of eligible RIRs will remain in the Reclamation Pool until such time sufficient address returns allow another round of allocations. This change was editorial and did not alter the substance of the Policy Draft. I bring this up because we want everyone to be considering the most current text in their assessments and be thoroughly and consistently informed. Bill Darte ARIN Advisory Council Primary Shepherd for 2010-10 -----Original Message----- From: arin-ppml-bounces at arin.net on behalf of Hannigan, Martin Sent: Tue 9/14/2010 12:06 AM To: arin-ppml at arin.net Subject: [arin-ppml] Suggested updates to Draft Policy 2010-10 (Global Hello PPML: A fair amount of feedback was received with regards to the Subject proposal. The original authors of the proposal discussed all of the feedback and additional suggestions are below: 1. Allocation method was unfair The intent was not for a single RIR to be able to be allocated all available address space in mass quantities. We do however want any available address space to be utilized if there is need. We've addressed what we would characterize as a mechanical issue. --new text Section 3. Address Allocations from the Reclamation Pool by the IANA Allocations from the Reclamation Pool may begin once the pool is declared active. Addresses in the Reclamation Pool must be allocated on a CIDR boundary. Allocations from the Reclamation Pool are subject to a minimum allocation unit equal to the minimum allocation unit of all RIRs and a maximum allocation unit of one /8. The Reclamation Pool will be divided on CIDR boundaries and distributed evenly to all eligible RIRs once each quarter. Any remainder not evenly divisible by the number of eligible RIRs based on a CIDR boundary equal to or larger than the minimum allocation unit will remain in the Reclamation Pool. Addresses that are left over will be held in the Reclamation Pool until additional IP addresses can be returned to rejoin addresses on CIDR boundaries to the Reclamation Pool or a minimum allocation unit is set to allow allocation from existing inventory. 2. Without excluding transition space, some RIR's would never be eligible We've defined a /10 credit to be applied for "all" pools of address space set-aside by any RIR that has them. --new text Section 4. RIR Eligibility for Receiving Allocations from the Reclamation Pool Upon the exhaustion of an RIR's free space pool and after receiving their final /8 from the IANA[3], an RIR will become eligible to request address space from the IANA Reclamation Pool when it publicly announces via its respective global announcements email list and by posting a notice on its website that it has exhausted its supply of IPv4 address space. Exhaustion is defined as an inventory of less than the equivalent of a single /8 and the inability to further assign address space to its customers in units equal to or shorter than the longest of any RIR's policy defined minimum allocation unit. Up to one /10 or equivalent of IPv4 address space specifically reserved for any special purpose by an RIR will not be counted against that RIR when determining eligibility unless that space was received from the IANA reclamation pool. Any RIR that is formed after the ICANN Board of Directors has ratified this policy is not eligible to utilize this policy to obtain IPv4 address space from the IANA. 3. Transfer Rights No plans to make suggestions that the AC modify transfer. 4. Additional comments One comment [Bill H.] seemed to adequately represent all who may believe that such a policy is not needed or required; 'No one in their right mind would return address space to an RIR considering how much it might be worth'. I'm aware of at least one entity that has signed up to return a /8 in the next month or two. Stay tuned. Best, -M< _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. Originally sent: Date: Tue, 14 Sep 2010 01:06:01 -0400 Re-queued by ESC7NET: Mon Sep 20 23:39:24 2010 -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Tue Sep 14 03:52:58 2010 From: farmer at umn.edu (David Farmer) Date: Tue, 14 Sep 2010 02:52:58 -0500 Subject: [arin-ppml] 2010-8: Rework of IPv6 assignment criteria Message-ID: <20100921044352.286F112B4997@sa.esc7.net> An HTML attachment was scrubbed... URL: From farmer at umn.edu Tue Sep 14 03:52:58 2010 From: farmer at umn.edu (David Farmer) Date: Tue, 14 Sep 2010 02:52:58 -0500 Subject: [arin-ppml] 2010-8: Rework of IPv6 assignment criteria Message-ID: <20100921044352.235B912B4992@sa.esc7.net> An HTML attachment was scrubbed... URL: From marty at akamai.com Tue Sep 21 09:12:53 2010 From: marty at akamai.com (Hannigan, Martin) Date: Tue, 21 Sep 2010 09:12:53 -0400 Subject: [arin-ppml] Suggested updates to Draft Policy 2010-10 (Global In-Reply-To: Message-ID: Bill, Something odd appears to happened with my mail client last evening so could you please ignore the message that you quote below? I?m enjoying the fact that I?m now able to send email while I?m asleep. Best, -M< On 9/21/10 6:30 AM, "Bill Darte" wrote: Thanks Marty, But the text you cite below as part of Section 3 was changed (as you know) by the AC to the following: 3. Address Allocations from the Reclamation Pool by the IANA Allocations from the Reclamation Pool may begin once the pool is declared active. Addresses in the Reclamation Pool must be allocated on a CIDR boundary. Allocations from the Reclamation Pool are subject to a minimum allocation unit equal to the minimum allocation unit of all RIRs and a maximum allocation unit of one /8. The Reclamation Pool will be divided on CIDR boundaries and distributed evenly to all eligible RIRs once each quarter. Any remainder not evenly divisible by the number of eligible RIRs will remain in the Reclamation Pool until such time sufficient address returns allow another round of allocations. This change was editorial and did not alter the substance of the Policy Draft. I bring this up because we want everyone to be considering the most current text in their assessments and be thoroughly and consistently informed. Bill Darte ARIN Advisory Council Primary Shepherd for 2010-10 -----Original Message----- From: arin-ppml-bounces at arin.net on behalf of Hannigan, Martin Sent: Tue 9/14/2010 12:06 AM To: arin-ppml at arin.net Subject: [arin-ppml] Suggested updates to Draft Policy 2010-10 (Global Hello PPML: A fair amount of feedback was received with regards to the Subject proposal. The original authors of the proposal discussed all of the feedback and additional suggestions are below: 1. Allocation method was unfair The intent was not for a single RIR to be able to be allocated all available address space in mass quantities. We do however want any available address space to be utilized if there is need. We've addressed what we would characterize as a mechanical issue. --new text Section 3. Address Allocations from the Reclamation Pool by the IANA Allocations from the Reclamation Pool may begin once the pool is declared active. Addresses in the Reclamation Pool must be allocated on a CIDR boundary. Allocations from the Reclamation Pool are subject to a minimum allocation unit equal to the minimum allocation unit of all RIRs and a maximum allocation unit of one /8. The Reclamation Pool will be divided on CIDR boundaries and distributed evenly to all eligible RIRs once each quarter. Any remainder not evenly divisible by the number of eligible RIRs based on a CIDR boundary equal to or larger than the minimum allocation unit will remain in the Reclamation Pool. Addresses that are left over will be held in the Reclamation Pool until additional IP addresses can be returned to rejoin addresses on CIDR boundaries to the Reclamation Pool or a minimum allocation unit is set to allow allocation from existing inventory. 2. Without excluding transition space, some RIR's would never be eligible We've defined a /10 credit to be applied for "all" pools of address space set-aside by any RIR that has them. --new text Section 4. RIR Eligibility for Receiving Allocations from the Reclamation Pool Upon the exhaustion of an RIR's free space pool and after receiving their final /8 from the IANA[3], an RIR will become eligible to request address space from the IANA Reclamation Pool when it publicly announces via its respective global announcements email list and by posting a notice on its website that it has exhausted its supply of IPv4 address space. Exhaustion is defined as an inventory of less than the equivalent of a single /8 and the inability to further assign address space to its customers in units equal to or shorter than the longest of any RIR's policy defined minimum allocation unit. Up to one /10 or equivalent of IPv4 address space specifically reserved for any special purpose by an RIR will not be counted against that RIR when determining eligibility unless that space was received from the IANA reclamation pool. Any RIR that is formed after the ICANN Board of Directors has ratified this policy is not eligible to utilize this policy to obtain IPv4 address space from the IANA. 3. Transfer Rights No plans to make suggestions that the AC modify transfer. 4. Additional comments One comment [Bill H.] seemed to adequately represent all who may believe that such a policy is not needed or required; 'No one in their right mind would return address space to an RIR considering how much it might be worth'. I'm aware of at least one entity that has signed up to return a /8 in the next month or two. Stay tuned. Best, -M< _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. Originally sent: Date: Tue, 14 Sep 2010 01:06:01 -0400 Re-queued by ESC7NET: Mon Sep 20 23:39:24 2010 -------------- next part -------------- An HTML attachment was scrubbed... URL: From marty at akamai.com Tue Sep 21 09:22:39 2010 From: marty at akamai.com (Hannigan, Martin) Date: Tue, 21 Sep 2010 09:22:39 -0400 Subject: [arin-ppml] Suggested updates to Draft Policy 2010-10 (Global In-Reply-To: Message-ID: Hi Bill, this actually looks like a problem on the list mailserver vs. my client. Please do ignore the last spew. Best, -M< On 9/21/10 6:30 AM, "Bill Darte" wrote: Thanks Marty, But the text you cite below as part of Section 3 was changed (as you know) by the AC to the following: 3. Address Allocations from the Reclamation Pool by the IANA Allocations from the Reclamation Pool may begin once the pool is declared active. Addresses in the Reclamation Pool must be allocated on a CIDR boundary. Allocations from the Reclamation Pool are subject to a minimum allocation unit equal to the minimum allocation unit of all RIRs and a maximum allocation unit of one /8. The Reclamation Pool will be divided on CIDR boundaries and distributed evenly to all eligible RIRs once each quarter. Any remainder not evenly divisible by the number of eligible RIRs will remain in the Reclamation Pool until such time sufficient address returns allow another round of allocations. This change was editorial and did not alter the substance of the Policy Draft. I bring this up because we want everyone to be considering the most current text in their assessments and be thoroughly and consistently informed. Bill Darte ARIN Advisory Council Primary Shepherd for 2010-10 -----Original Message----- From: arin-ppml-bounces at arin.net on behalf of Hannigan, Martin Sent: Tue 9/14/2010 12:06 AM To: arin-ppml at arin.net Subject: [arin-ppml] Suggested updates to Draft Policy 2010-10 (Global Hello PPML: A fair amount of feedback was received with regards to the Subject proposal. The original authors of the proposal discussed all of the feedback and additional suggestions are below: 1. Allocation method was unfair The intent was not for a single RIR to be able to be allocated all available address space in mass quantities. We do however want any available address space to be utilized if there is need. We've addressed what we would characterize as a mechanical issue. --new text Section 3. Address Allocations from the Reclamation Pool by the IANA Allocations from the Reclamation Pool may begin once the pool is declared active. Addresses in the Reclamation Pool must be allocated on a CIDR boundary. Allocations from the Reclamation Pool are subject to a minimum allocation unit equal to the minimum allocation unit of all RIRs and a maximum allocation unit of one /8. The Reclamation Pool will be divided on CIDR boundaries and distributed evenly to all eligible RIRs once each quarter. Any remainder not evenly divisible by the number of eligible RIRs based on a CIDR boundary equal to or larger than the minimum allocation unit will remain in the Reclamation Pool. Addresses that are left over will be held in the Reclamation Pool until additional IP addresses can be returned to rejoin addresses on CIDR boundaries to the Reclamation Pool or a minimum allocation unit is set to allow allocation from existing inventory. 2. Without excluding transition space, some RIR's would never be eligible We've defined a /10 credit to be applied for "all" pools of address space set-aside by any RIR that has them. --new text Section 4. RIR Eligibility for Receiving Allocations from the Reclamation Pool Upon the exhaustion of an RIR's free space pool and after receiving their final /8 from the IANA[3], an RIR will become eligible to request address space from the IANA Reclamation Pool when it publicly announces via its respective global announcements email list and by posting a notice on its website that it has exhausted its supply of IPv4 address space. Exhaustion is defined as an inventory of less than the equivalent of a single /8 and the inability to further assign address space to its customers in units equal to or shorter than the longest of any RIR's policy defined minimum allocation unit. Up to one /10 or equivalent of IPv4 address space specifically reserved for any special purpose by an RIR will not be counted against that RIR when determining eligibility unless that space was received from the IANA reclamation pool. Any RIR that is formed after the ICANN Board of Directors has ratified this policy is not eligible to utilize this policy to obtain IPv4 address space from the IANA. 3. Transfer Rights No plans to make suggestions that the AC modify transfer. 4. Additional comments One comment [Bill H.] seemed to adequately represent all who may believe that such a policy is not needed or required; 'No one in their right mind would return address space to an RIR considering how much it might be worth'. I'm aware of at least one entity that has signed up to return a /8 in the next month or two. Stay tuned. Best, -M< _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. Originally sent: Date: Tue, 14 Sep 2010 01:06:01 -0400 Re-queued by ESC7NET: Mon Sep 20 23:39:24 2010 -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Tue Sep 21 09:38:36 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 21 Sep 2010 06:38:36 -0700 Subject: [arin-ppml] 2010-8: Rework of IPv6 assignment criteria In-Reply-To: <0267B5481DCC474D8088BF4A25C7F1DF5517F26CE6@XCH-NW-05V.nw.nos.boeing.com> References: <4C8F29DA.8020003@umn.edu><4C9552B9.4000503@umn.edu> <10C69619-8742-4E5B-A527-D6A010BE3399@icann.org> <0267B5481DCC474D8088BF4A25C7F1DF5517F26CE6@XCH-NW-05V.nw.nos.boeing.com> Message-ID: <762E6536-FF9E-47F0-A6BF-7E9A8A2BB1F4@delong.com> On Sep 20, 2010, at 10:59 AM, Davis, Terry L wrote: > All > > As you think about this, don't forget truly global international infrastructures. The International Civil Aviation Organization has published the requirement for new (Next generation) Air Traffic Management systems to utilize IPv6 addressing. Currently they provide OSI Air Traffic Network addresses for all existing commercial and civil aviation globally to "all" aircraft owners/operators. > > They likely will be looking for a single global PI IPv6 allocation for this new IPv6 based Air Traffic Network infrastructure soon. > ICAO would be an LIR for that purpose, not an end-user. > Take care > Terry > > PS: Also don't forget that other folks like international non-profit organizations, international trade organizations, multi-entity national infrastructures (rail, grids), and others will likely also want IPv6 PI spaces too. > Many of these would be LIRs as well. The ones that are end-users would apply based on the number of sites supported, getting at least 1 /48 for every site with lots and lots of room to grow. Owen > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net >> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Leo Vegoda >> Sent: Monday, September 20, 2010 9:13 AM >> To: David Farmer >> Cc: arin-ppml at arin.net >> Subject: Re: [arin-ppml] 2010-8: Rework of IPv6 assignment criteria >> >> On 18 Sep 2010, at 5:00, David Farmer wrote: >> >> [...] >> >>> Furthermore, very large hierarchical end-user networks, >> especially for a >>> large multinational corporation, are not precluded from considering >>> themselves as an ISP or LIR, and then starting with a /32 >> and being able >>> to avail themselves of HD-Ratio. That might be more >> appropriate anyway, >>> the networks for large multinational corporation with many >> independent >>> business units, probably have much more in common with ISPs >> then the >>> majority of other end-user networks. >> >> I think this would resolve the problem for larger, more >> complex end user networks. >> >> Leo >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From owen at delong.com Tue Sep 21 09:34:43 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 21 Sep 2010 06:34:43 -0700 Subject: [arin-ppml] What is a "host"? In-Reply-To: <4C97A0E6.1090800@umn.edu> References: <3026D718-E8C1-4549-9E85-FB9C2139FC68@tcb.net> <03aa01cb55d3$2b09bcf0$811d36d0$@com> <984E935A-E2BE-4D5D-B24E-A81CE9523373@delong.com> <0F29D1BA57992E4CAB5AD2C9AE7B42391CF4E005@EMV01-UKBR.domain1.systemhost.net> <95E4C0A8-4A81-4D0B-8FA1-BB65AC0244E5@delong.com> <0F29D1BA57992E4CAB5AD2C9AE7B423935E05450@EMV01-UKBR.domain1.systemhost.net> <0F29D1BA57992E4CAB5AD2C9AE7B423935E057B2@EMV01-UKBR.domain1.systemhost.net> <4C97A0E6.1090800@umn.edu> Message-ID: <29BFC955-DBC3-4AC2-BAD1-689299A36456@delong.com> >> >> Given that we are talking about IPv6 renumbering, not IPv4 renumbering, >> subnets still seems like a good measure. In IPv6, the subnets are unchanged >> and you just change the network prefix handed out by SLAAC or DHCPv6. > > In theory renumbering in IPv6 is easier than in IPv4, but in practice, while it is easier, it is not that significantly easier. Especially, when compared to renumbering IPv4 with DHCP, DNS is the biggest hassle in both cases. This might have been different if we were able to figure out A6 records, or something like them. > If you think DNS is the biggest hassle in renumbering, you have never renumbered a complex environment. The biggest hassle in renumbering any complex real-world environment is the number of places your addresses appear in configuration files you do not manage. + Partner VPNs + Customer VPNs + Customer links + Customer Firewall Rulesets + Partner Firewall Rulesets + Sometimes Employee {firewall,vpn,router} configurations Owen From owen at delong.com Tue Sep 21 09:41:51 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 21 Sep 2010 06:41:51 -0700 Subject: [arin-ppml] 2010-8: Rework of IPv6 assignment criteria In-Reply-To: References: <4C8F29DA.8020003@umn.edu> <4C9552B9.4000503@umn.edu> Message-ID: <20DA88DB-49C5-424D-8583-1D1D9BF4C430@delong.com> On Sep 20, 2010, at 11:08 AM, Gary Buhrmaster wrote: > On Sun, Sep 19, 2010 at 00:00, David Farmer wrote: > .... >> Furthermore, very large hierarchical end-user networks, especially for a >> large multinational corporation, are not precluded from considering >> themselves as an ISP or LIR, and then starting with a /32 and being able to >> avail themselves of HD-Ratio. That might be more appropriate anyway, the >> networks for large multinational corporation with many independent business >> units, probably have much more in common with ISPs then the majority of >> other end-user networks. > > I believe for many "large" end-users, this is the most logical approach. > > The posture child in a previous e-mail thread was HP. While > I have no idea how HP networking operates internally, my > first thought is that it is likely they are more like an ISP/LIR > in that they provide service to their BU's/departments/whatevers > and delegate address ranges to those groups for their > uses. > HP has many many many buildings (sites). Since they can get a /48 for each one under this policy (and lots of extra /48s, beyond that, too), I'm pretty sure they could get by and would be no worse off with this policy than with one involving HD Ratios. > I would like to be sure that ARIN policy make it easy for such > "end-users" to consider themselves ISP/LIRs (/32) where > appropriate and justified. > That has more to do with how we frame the ISP/LIR policy and the ARIN fee structure than it does this policy. This policy is about end users that want to be considered end users. Owen From owen at delong.com Tue Sep 21 09:47:37 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 21 Sep 2010 06:47:37 -0700 Subject: [arin-ppml] What is a "host"? In-Reply-To: <0F29D1BA57992E4CAB5AD2C9AE7B423935E05857@EMV01-UKBR.domain1.systemhost.net> References: <3026D718-E8C1-4549-9E85-FB9C2139FC68@tcb.net> <03aa01cb55d3$2b09bcf0$811d36d0$@com> <984E935A-E2BE-4D5D-B24E-A81CE9523373@delong.com> <0F29D1BA57992E4CAB5AD2C9AE7B42391CF4E005@EMV01-UKBR.domain1.systemhost.net> <95E4C0A8-4A81-4D0B-8FA1-BB65AC0244E5@delong.com> <0F29D1BA57992E4CAB5AD2C9AE7B423935E05450@EMV01-UKBR.domain1.systemhost.net> <0F29D1BA57992E4CAB5AD2C9AE7B423935E057B2@EMV01-UKBR.domain1.systemhost.net> <0F29D1BA57992E4CAB5AD2C9AE7B423935E05857@EMV01-UKBR.domain1.systemhost.net> Message-ID: <45C20935-F8C6-4AB3-9903-E73848E4A775@delong.com> >> Respectfully, the assumption that IPv6 renumbering will prove >> meaningfully less costly than IPv4 renumbering is still unfounded. >> Wait for it to play out in large, real-world deployments before >> building this assumption into policy. > > Has anyone done an in-depth analysis of this? There are many organizations > that have been running IPv6 at scale for many years now, and most of them > do have experience of renumbering. We need more facts and less guesswork. > I can speak from my own experience renumbering both IPv4 and IPv6 networks... There are many aspects to renumbering any but the simplest of environments. The easiest aspects (renumbering dynamically assigned hosts without DNS) is even easier in IPv6 than it was in IPv4 and more seemless. All of the other aspects are an identical effort. In order of increasing difficulty, here are the ones I can recall off the top of my head. I think it is a fairly complete list: Static Hosts Hosts with forward DNS DNS Servers Hosts whose addresses appear in multiple configuration files you control Hosts whose addresses appear in configuration files you do not control within your organization Hosts whose addresses appear in configuration files in devices controlled by third party organizations Owen From owen at delong.com Tue Sep 21 10:03:35 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 21 Sep 2010 07:03:35 -0700 Subject: [arin-ppml] 2010-8: Rework of IPv6 assignment criteria In-Reply-To: <6B6FF1EB-019A-454F-BD66-115B48AA9C8C@icann.org> References: <4C8F29DA.8020003@umn.edu> <4C9552B9.4000503@umn.edu> <10C69619-8742-4E5B-A527-D6A010BE3399@icann.org> <91294978-61DD-42C3-AF15-08933474AD9E@delong.com> <6B6FF1EB-019A-454F-BD66-115B48AA9C8C@icann.org> Message-ID: On Sep 20, 2010, at 1:43 PM, Leo Vegoda wrote: > On 20 Sep 2010, at 10:47, Owen DeLong wrote: > > [...] > >> I think the simpler (and much cheaper for the organization) approach >> would be to realize that the "Large Complex" networks are almost never >> implemented in a single building. > > I didn't realise that the proposal was for the organization to receive a separate PI assignment for each building or campus in their network. I had thought the proposal would allow an organization to receive a single (shortish) prefix to be used by multiple campus networks, data centers etc... > The proposal allows them to receive a single (shortish) prefix which includes at least one /48 per building in their network. The prefix length is based on the number of /48s they need where it is at least large enough that current need does not exceed 75% of the prefix issued. There are provisions for more than a /48 per site if an entity somehow has exceedingly large sites. We expect that to be a clause that is never used as we've been unable to fathom the idea of a single-tenant structure which needs more than 65,536 subnets. A "site" is defined as a single tenant structure, or, a single tenant in a multi-tenant structure. If you have 30 buildings on a campus, this policy would allow you to get at least 40 /48s worth of space. Rounding that up to a nibble boundary, you would receive a /40 (256 /48s). If you have 350 offices in cities around the world, you would be entitled to at least 467 /48s, which, rounded up to a nibble boundary becomes 4096 /48s, or, a /36. Given this, do you still think HD ratio is needed? Owen From info at arin.net Tue Sep 21 10:10:45 2010 From: info at arin.net (ARIN) Date: Tue, 21 Sep 2010 10:10:45 -0400 Subject: [arin-ppml] Draft Policy 2010-14: Standardize IP Reassignment Registration Requirements In-Reply-To: <4C61C448.7090403@arin.net> References: <4C61C448.7090403@arin.net> Message-ID: <4C98BCE5.30308@arin.net> Draft Policy 2010-14 Standardize IP Reassignment Registration Requirements Attached is the ARIN staff assessment of 2010-14. This draft policy is open for discussion on this mailing list and will be on the agenda at the upcoming ARIN Public Policy Meeting in Atlanta. 2010-14 is below and available at: https://www.arin.net/policy/proposals/2010_14.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Staff Assessment of Draft Policy 2010-14 (version dated 10 August 2010) Standardize IP Reassignment Registration Requirements 1. Proposal Summary (Staff Understanding) This policy: ? Tightens the requirements for SWIP or RWHOIS registration information ? Replaces the existing Cable Address Policy with a broader policy applicable to all residential dynamic addressing pools ? Extends its application to IPv6 ? Better defines what a residential customer is ? Changes reassignment policy so that /64s and larger networks must be registered via SWIP or RWhois ? Adds a criterion for staff to initiate a NRPM 12 resource review audit. 2. Comments A. ARIN Staff Comments ? This proposal would replace the 3 existing qualifying criteria of the Cable Policy (NRPM section 4) with the single criterion of must show >50% utilization. o It is staff?s observation that the existing cable policy works well for cable providers as is and staff cannot discern what problem this section of the proposal is attempting to solve. o The current cable policy requires 80% of the ISP?s address space to be provisioned to hardware and to be reassigned, with a 50 ? 80% utilization rate. This new proposal removes the 80% requirement, which would allow a provider to provision and reassign only 50% of their most recent allocation. The result seems to be lowered efficiency of overall address space usage. o The text in this section is somewhat unclear and confusing as written. ? Because this proposal would apply to all residential dynamic addressing pools (in addition to cable), it would likely be beneficial for many of ARIN?s customers who share very similar technologies to the cable industry, but have never been able to apply under the cable policy (technologies like dsl, fiber to the home, etc.). ? This proposal provides a well-defined explanation of what a residential customer is and will be beneficial to both the community and to the staff. The existing definition of ?residential customer? has caused some confusion for customers. B. ARIN General Counsel Currently, counsel is reviewing US and Canadian law regarding the policy?s suggested changes to the balance in current ARIN policy on customer ?privacy? and business proprietary information related to residential customers. At this point there is no significant legal issue. We will update this as soon as possible. 3. Resource Impact This policy would have moderate to major resource impact. It is estimated that implementation would occur within 6 months to 9 months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement: ? Potential Database impact if all /64s and larger assignments must now be swipped (there are ~4 billion /64s in a /32 so the scale of this goes beyond anything ARIN has seen). ? Changes to current business processes ? Updated templates ? Updated guidelines ? Staff training Full draft policy text below: > > > > Draft Policy 2010-14 > Standardize IP Reassignment Registration Requirements > > Version/Date: 10 August 2010 > > Policy statement: > > ## Definitions ## > > - Add: > > 2.3. Organizational Information > > When required, organization Information must include at a minimum: > Legal name, street address, city, state, zip code equivalent and at > least one valid technical and one valid abuse POC. Each POC shall be > designated by the organization and must include at least a verifiable > email address and phone number. > > 2.12. Residential Customer > > End-users who are individual persons and not organizations and who > receive service at a place of residence for personal use only are > considered residential customers. > > ## IPv4 ## > > - Rename 4.2.3.7. "Reassignment information" to "Registration" and add > text: > > ISPs are required to demonstrate efficient use of IP address space > allocations by providing appropriate documentation, including but not > limited to assignment histories, showing their efficient use. > > - Rename 4.2.3.7.1. "Customer organization information" to > "Reassignment Information" and replace text with: > > Each IPv4 assignment containing a /29 or more addresses shall be > registered in the WHOIS directory via SWIP or a distributed service > which meets the standards set forth in section 3.2. Reassignment > registrations shall include each client's organizational information, > except where specifically exempted by this policy. > > - Strike sections 4.2.3.7.2., 4.2.3.7.4. and 4.2.3.7.5. > > - Renumber section 4.2.3.7.3. to 4.2.3.7.2., rename to "Assignments > visible within 7 days" and replace text with: > > All assignments shall be made visible as required in section 4.2.3.7.1 > within seven calendar days of assignment. > > - Renumber and replace 4.2.3.7.6. Residential Customer Privacy with: > > 4.2.3.7.3. Residential Subscribers > > 4.2.3.7.3.1. Residential Market Area > > ISPs that assign address space to the infrastructure to which their > customers connect rather than to individual subscribers must register > assignment information regarding each market area holding such an > address block. Market area reassignments shall be registered with the > network name used to identify each market area. Any assignment to > specific end-users holding /29 and larger blocks still requires > registration. A >50% utilization rate shall be considered efficient > for market area reassignments from the ISPs most recent allocation. > > 4.2.3.7.3.2. Residential Customer Privacy > > To maintain the privacy of their residential customers, an > organization with downstream residential customers holding /29 and > larger blocks may substitute that organization's name for the > customer's name, e.g. 'Private Customer - XYZ Network', and the > customer's street address may read 'Private Residence'. Each private > downstream residential reassignment must have accurate upstream Abuse > and Technical POCs visible on the WHOIS directory record for that > block. > > - Strike section 4.2.6. "Cable Address Space Policy" > > ## IPv6 ## > > - Replace Section 6.5.5. with: > > 6.5.5. Registration > > ISPs are required to demonstrate efficient use of IP address space > allocations by providing appropriate documentation, including but not > limited to assignment histories, showing their efficient use. > > 6.5.5.1. Reassignment information > > Each IPv6 assignment containing a /64 or more addresses shall be > registered in the WHOIS directory via SWIP or a distributed service > which meets the standards set forth in section 3.2. Reassignment > registrations shall include each client's organizational information, > except where specifically exempted by this policy. > > 6.5.5.2. Assignments visible within 7 days > > All assignments shall be made visible as required in section 4.2.3.7.1 > within seven calendar days of assignment. > > 6.5.5.3. Residential Subscribers > > 6.5.5.3.1. Residential Market Area > > ISPs that assign address space to the infrastructure to which their > customers connect rather than to individual subscribers must register > assignment information regarding each market area holding such an > address block. Market area reassignments shall be registered with the > network name used to identify each market area. Any assignment to > specific end-users holding /64 and larger blocks still requires > registration. A >50% utilization rate shall be considered efficient > for market area reassignments from the ISPs most recent allocation. > > 6.5.5.3.2. Residential Customer Privacy > > To maintain the privacy of their residential customers, an > organization with downstream residential customers holding /64 and > larger blocks may substitute that organization's name for the > customer's name, e.g. 'Private Customer - XYZ Network', and the > customer's street address may read 'Private Residence'. Each private > downstream residential reassignment must have accurate upstream Abuse > and Technical POCs visible on the WHOIS record for that block. > > ## Resource Review ## > > - Move section 12.2. paragraph 2. bullet c. to bullet d. and insert > the following: > > c. whenever ARIN has reason to believe that an organization is not > complying with reassignment policies, or > > -- > > Rationale: > > #Changes in this version: > After many conversations both at and following the last public policy > meeting in Toronto, some revisions have been made. These all address > specific concerns raised by multiple interested parties: > 1) Organizational Information ? Phone number, street address and abuse > POC now required. > 2) Residential Customer ? Added ?for personal use only? to the > definition. > 3) Registration (4.2.3.7 & 6.5.5) ? Added ?but not limited to? WRT > assignment histories. > 4) IPv6 ? Requires all /64 and larger blocks to be registered. > 5) Resource Review ? Added this section. > > #Short Rational: > This proposal intends to do several things: > 1) Bring IPv4 and IPv6 policy more in line with each other to make the > NRPM easier to understand and comply with - at least as it relates to > reassignment information. > 2) Specifically define what organizational information is required to > be added to WHOIS when reassignments are made to client organizations. > 3) To specifically state that a client organization may designate the > POC of their choice for any/all WHOIS entries in policy. This includes > designating an upstream POC as their own preferred POC (which allows > for simple reassignments). > 4) Expands the privileges previously reserved solely for IPv4 cable > ISPs to all ISPs/LIRs with residential/dhcp-type subscribers. > 5) Specifically define the term "residential customer." > 6) Allow ARIN to conduct resource reviews based on failure to comply > with registration / reassignment policies. > > #Expanded Rational: > 1) This policy restructures the reassignment and registration sections > of the IPv4 and IPv6 policies. > a) The IPv4 section is renamed "registration." > b) The IPv4 policy is shortened and rewritten for clarity. > c) The IPv6 policy is totally rewritten in a format that matches the > IPv4 policy. > * These structural changes are meant to make it easier to compare the > two sections. I believe that having the IPv6 and IPv4 policies written > in completely different formats and structures (as they are in many > cases now) confuses the issues and makes it very hard to understand > what is different and what is the same across the two sections. > Bringing them into a similar format should help ease the migration to > IPv6 as folks can quickly and easily understand the differences and > the similarities. > d) The IPv6 policy is altered from a /56 minimum needing to be > registered to a /64. A /64 is a single IPv6 subnet where as a /56 > contains many subnets (that should all be recorded in the WHOIS > directory if handed out to other organizations). > > 2) This policy adds a definition of "organizational information" which > is used in the existing policy but not currently defined anywhere in > the NRPM. > a) The definition states that legal name and physical address are > required for client organizations. > b) The definition states that POCs are required but can be designated > by the client organization - it spells out that the client org can > choose to use their upstream as a POC. > c) The definition requires that each POC have a valid email address > and phone number. > > 3) This policy takes the privileges granted specifically to IPv4 cable > operators in section 4.2.6. "Cable Address Space Policy" and grants > them to all ISPs who serve residential areas. > a) It allows all ISPs with residential coverage to > register/swip/rwhois an entire market area. > b) It retains the existing residential customer privacy policy for all > customers with larger IP blocks. > * This change removes the need for any ISP to enter residential > customers into whois at all. > > 4) This policy also extends the >50% utilization rate, currently > granted only to IPv4 cable operators, to all ISPs with a residential > footprint. > * This change offsets the ability to register/swip/rwhois market > areas. For all other allocation types, efficient utilization is based > on SWIPs, not on actual utilization. When an organization is able to > SWIP an entire market area, this must be checked against actual > utilization. This policy maintains the current line set at >50%. > **The 50% mark on the most recent allocation is because you can > quickly distribute most of your address space across your provisioning > footprint, leaving nothing left for growth while the lease count of > the provisioned customers catches up to the blocks allocated. (Dan > Alexander's words) > > 5) Current policy references "residential customers" but there is no > current definition of residential customers in the NRPM. This has > reportedly been an on-going problem for ARIN and it?s customers. > > 6) Not properly registering reassignment information could be a sign > of other improper or illicit behavior and should justify a resource > review (audit) by ARIN when necessary, regardless of when the last > review took place. > > > > > > From leo.vegoda at icann.org Tue Sep 21 14:57:08 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Tue, 21 Sep 2010 11:57:08 -0700 Subject: [arin-ppml] 2010-8: Rework of IPv6 assignment criteria In-Reply-To: References: <4C8F29DA.8020003@umn.edu> <4C9552B9.4000503@umn.edu> <10C69619-8742-4E5B-A527-D6A010BE3399@icann.org> <91294978-61DD-42C3-AF15-08933474AD9E@delong.com> <6B6FF1EB-019A-454F-BD66-115B48AA9C8C@icann.org> Message-ID: <3F6CE5AC-7172-4507-91C7-CE9AE8730C32@icann.org> On 21 Sep 2010, at 7:03, Owen DeLong wrote: [...] > Given this, do you still think HD ratio is needed? My issue isn't that the HD-ratio is the best mechanism, just that the same kind of scoring mechanism should be available to all address space users. As you've indicated you'll be proposing a change for allocations made to ISPs I'll wait and see what you propose. Regards, Leo From fred.wettling at bechtel.com Wed Sep 22 08:09:53 2010 From: fred.wettling at bechtel.com (Wettling, Fred) Date: Wed, 22 Sep 2010 08:09:53 -0400 (EDT) Subject: [arin-ppml] 2010-8: Rework of IPv6 assignment criteria In-Reply-To: Message-ID: <468033556.69336.1285157393280.JavaMail.root@ashs90053.becpsn.com> I support 2010-8, preferring the simple clean 75% approach over the HD-ratio.? /48 per site is the right size.? Fred Wettling -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at arin.net Wed Sep 22 15:58:06 2010 From: info at arin.net (ARIN) Date: Wed, 22 Sep 2010 15:58:06 -0400 Subject: [arin-ppml] 2010-8: Rework of IPv6 assignment criteria Message-ID: <4C9A5FCE.4030709@arin.net> Draft Policy 2010-8 Rework of IPv6 assignment criteria Attached is the ARIN staff assessment of the revised 2010-8. This draft policy is open for discussion on this mailing list and will be on the agenda at the upcoming ARIN Public Policy Meeting in Atlanta. 2010-8 is below and available at: https://www.arin.net/policy/proposals/2010_8.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Staff Assessment of Draft Policy 2010-8 (version dated 14 September 2010) Rework of IPv6 assignment criteria 1. Proposal Summary (Staff Understanding) This policy replaces the existing IPv6 assignment policy established in NRPM 6.5.8. It establishes four optional criteria for qualifying for an initial IPv6 assignment and provides criteria for requests larger than the default /48, and for subsequent assignments. Additional changes include the replacement of the HD ratio as the standard utilization metric with a utilization percentage; the elimination of the requirement that ARIN reserve adjacent space when making v6 assignments; and changes to the initial and subsequent assignment sizes. Finally, it encourages organizations to aggregate any non-contiguous direct assignments they have. 2. Comments A. ARIN Staff Comments ? This policy requires staff to automatically issue a /40 for networks with 12-192 sites. A /40 is the point at which the fee schedule jumps to the small fee. So, an org that formerly could request a smaller block (a /42 for example), which would have been an x-small block with a $1,250 fee, must now get a /40 and pay the higher fee of $2,250. ? Staff finds the policy text in the following sections to be unclear and confusing, which makes it difficult for staff to implement. If the text were to be simplified and written in a more straightforward manner, it would become more understandable, and therefore more likely to be utilized by the community. o Section 6.5.8.2.1 "Where a site is a discrete location that is part of an organization?s network." This seems out of context to both of the adjacent sentences and we aren?t sure how it applies. o Section 6.5.8.2.2 "An extra-large site will receive the smallest prefix such that the total subnet utilization justified does not exceed 25%." o Section 6.5.8.2.3 "More than 3,072 sites justified, receives a /32 assignment or larger. In cases where more than 3,072 sites are justified, an assignment of the smallest prefix, aligned on a nibble boundary, will be made such that the total utilization based on the number of sites justified above does not exceed 75%." o Section 6.5.8.3 "A subsequent assignment is justified when the total utilization based on the number of sites justified exceeds 75% across all of an organization?s assignments" ? It seems inconsistent to have the end-user IPv6 policy use utilization percentage while the ISP IPv6 policy uses HD ratio to measure utilization. B. ARIN General Counsel This proposal poses no significant legal issues. 3. Resource Impact This policy would have minimal resource impact. It is estimated that implementation would occur within 3 months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement: * Updated guidelines * Staff training Full draft policy text below: > Draft Policy 2010-8 > Rework of IPv6 assignment criteria > Date: 9/14/2010 > Policy statement: > Replace section 6.5.8 as follows; > > 6.5.8. Direct assignments from ARIN to end-user organizations > > 6.5.8.1 Initial Assignment Criteria > > Organizations may justify an initial assignment for addressing devices > directly attached to their own network infrastructure, with an intent > for the addresses to begin operational use within 12 months, by meeting > one of the following criteria: > > a. Having a previously justified IPv4 end-user assignment from ARIN or > one of its predecessor registries, or; > > b. Currently being IPv6 Multihomed or immediately becoming IPv6 > Multihomed and using an assigned valid global AS number, or; > > c. By having a network consisting of a total of 1000 or more hosts, or; > > d. By providing a reasonable technical justification indicating why > IPv6 > addresses from an ISP or other LIR are unsuitable. > > Examples of justifications for why addresses from an ISP or other LIR > may be unsuitable include, but are not limited to: > > ? An organization that operates infrastructure critical to life safety > or the functioning of society can justify the need for an assignment > based on the fact that renumbering would have a broader than expected > impact than simply the number of hosts directly involved. These would > include: hospitals, fire fighting, police, emergency response, power or > energy distribution, water or waste treatment, traffic management and > control, etc? > ? Regardless of the number of hosts directly involved, an organization > can justify the need for an assignment if renumbering would affect 1000 > or more individuals either internal or external to the organization. > ? An organization with a network not connected to the Internet can > justify the need for an assignment by documenting a need for guaranteed > uniqueness, beyond the statistical uniqueness provided by ULA (see RFC > 4193). > ? An organization with a network not connected to the Internet, such as > a VPN overlay network, can justify the need for an assignment if they > require authoritative delegation of reverse DNS. > > 6.5.8.2 Initial assignment size > > Organizations that meet at least one of the initial assignment criteria > above are eligible to receive an initial assignment of /48. Requests > for > larger initial assignments, reasonably justified with supporting > documentation, will be evaluated based on the number of sites in an > organization?s network and the number of subnets needed to support any > extra-large sites defined below. > > 6.5.8.2.1 /48 per site > > An organization may request up to a /48 for each site in its network, > including any sites that will be operational within 12 months. Where a > site is a discrete location that is part of an organization?s network. > In the case of a multi-tenant building, each organization located at > the > site may separately justify a /48 for its network at the site. > > A campus with multiple buildings may be considered as one or multiple > sites, based on the implementation of its network infrastructure. For > a > campus to be considered as multiple sites, reasonable technical > documentation must be submitted describing how the network > infrastructure is implemented in a manner equivalent to multiple sites. > > 6.5.8.2.2 Extra-large site > > In rare cases, an organization may request more than a /48 for an > extra-large site which requires more than 16,384 /64 subnets. In such > a > case, a detailed subnet plan must be submitted for each extra-large > site > in an organization?s network. An extra-large site will receive the > smallest prefix such that the total subnet utilization justified does > not exceed 25%. Each extra-large site will be counted as an equivalent > number of /48 sites. > > 6.5.8.2.3 Larger initial assignments > > Larger initial assignments will be determined based on the number of > sites justified above, aligned on a nibble boundary using the following > table: > > More than 1 but less than or equal to 12 sites justified, receives a > /44 > assignment; > More than 12 but less than or equal to 192 /sites justified, receives a > /40 assignment; > More than 192 but less than or equal to 3,072 sites justified, receives > a /36 assignment; > More than 3,072 sites justified, receives a /32 assignment or larger. > > In cases where more than 3,072 sites are justified, an assignment of > the > smallest prefix, aligned on a nibble boundary, will be made such that > the total utilization based on the number of sites justified above does > not exceed 75%. > > 6.5.8.3 Subsequent assignments > > Requests for subsequent assignments with supporting documentation will > be evaluated based on the same criteria as an initial assignment under > 6.5.8.2 with the following modifications: > > a. A subsequent assignment is justified when the total utilization > based > on the number of sites justified exceeds 75% across all of an > organization?s assignments. Except, if the organization received an > assignment per section 6.11 IPv6 Multiple Discrete Networks, such > assignments will be evaluated as if it were to a separate organization. > > Organizations may have multiple separate assignments that should be > considered in total, due to previous subsequent assignments made per > clause 6.5.8.3.c below, or through Mergers and Acquisitions in section > 8.2. > > b. When possible subsequent assignments will result it the expansion of > an existing assignment by one or more nibble boundaries as justified. > > c. If it is not possible to expand an existing assignment, or to expand > it adequately to meet the justified need, then a separate new > assignment > will be made of a size as justified. > > 6.5.8.4 Consolidation and return of separate assignments > > Organizations with multiple separate assignments should consolidate > into > a single aggregate, if feasible. If an organization stops using one or > more of its separate assignments, any unused assignments must be > returned to ARIN. > > Rationale: > > This proposal provides a complete rework of the IPv6 end-user > assignment > criteria, removing the dependency on IPv4 policy, providing clear > guidance in requesting larger initial assignments, and eliminating > HD-Ratio as criteria for evaluating end-user assignments. > > The HD-Ratio is replaced with a simplified 75% utilization threshold > based on nibble boundaries for end-user assignments. This threshold > is > somewhat more restrictive for larger assignments, while slightly less > restrictive for the smaller /44 assignments, than the HD-Ratio. > However, in both cases it is much easier for an end-user to understand > the policy criteria that applies to them. > > The following general concepts are included: > > ? Previously justified IPv4 resources may be used to justify the need > for IPv6 resources > ? Internet multihoming is sufficient justification for an IPv6 end-user > assignment in and of itself > ? Networks with more than 1000 hosts have a justified need for IPv6 > resources; as is the case in current policy, it is just more clearly > stated without relying on a reference to, and the consequences of, IPv4 > policy > ? Other end-users must justify why an ISP or LIR assignment is not > sufficient for their needs > ? Organizations with multiple sites may receive a /48 for each site in > their network > ? A campus with multiple buildings may be considered as one or multiple > sites, based on the implementation of its network infrastructure > ? Reservations are no longer necessary as ARIN has committed to sparse > assignment for IPv6 > ? Providing sufficiently large initial assignments based on nibble > boundaries along with sparse assignments will reduce route table growth > caused solely by subsequent assignments > > The 25% subnet utilization for an extra-large site is proposed as the > threshold for a larger prefix in order to allow an extra-large site > enough room to create an organized subnet plan. Requiring denser usage > would make it almost impossible for an extra-large site to maintain any > kind of organized subnet plan. Furthermore, even at 25% utilization, > more than 16,384 subnets are required to justify more than a /48 for a > site. Few, if any, sites can actually meet or exceed this threshold. > > The ARIN Board of Trusties should consider incentives that provide > additional motivation for end-users to consolidate into a single > aggregate per section 6.5.8.4 of this policy. > > Timetable for implementation: Immediate From Skeeve at eintellego.net Thu Sep 23 17:22:12 2010 From: Skeeve at eintellego.net (Skeeve Stevens) Date: Fri, 24 Sep 2010 07:22:12 +1000 Subject: [arin-ppml] 2010-8: Rework of IPv6 assignment criteria In-Reply-To: <4C9A5FCE.4030709@arin.net> References: <4C9A5FCE.4030709@arin.net> Message-ID: <292AF25E62B8894C921B893B53A19D9739AF595885@BUSINESSEX.business.ad> > > 6.5.8. Direct assignments from ARIN to end-user organizations > > > 6.5.8.1 Initial Assignment Criteria > > Organizations may justify an initial assignment for addressing devices directly attached to their own network infrastructure, with an intent for the addresses to begin operational use within 12 months, by meeting one of the following criteria: > > > a. Having a previously justified IPv4 end-user assignment from ARIN or one of its predecessor registries, or; > > > b. Currently being IPv6 Multihomed or immediately becoming IPv6 Multihomed and using an assigned valid global AS number, or; > > > c. By having a network consisting of a total of 1000 or more hosts, or; > > > d. By providing a reasonable technical justification indicating why IPv6 addresses from an ISP or other LIR are unsuitable. > > > Examples of justifications for why addresses from an ISP or other LIR may be unsuitable include, but are not limited to: > > > * An organization that operates infrastructure critical to life safety or the functioning of society can justify the need for an assignment based on the fact that renumbering would have a broader than expected impact than simply the number of hosts directly involved. These would include: hospitals, fire fighting, police, emergency response, power or energy distribution, water or waste treatment, traffic management and control, etc... > > > * Regardless of the number of hosts directly involved, an organization can justify the need for an assignment if renumbering would affect 1000 or more individuals either internal or external to the organization. > > > * An organization with a network not connected to the Internet can justify the need for an assignment by documenting a need for guaranteed uniqueness, beyond the statistical uniqueness provided by ULA (see RFC 4193). > > > * An organization with a network not connected to the Internet, such as a VPN overlay network, can justify the need for an assignment if they require authoritative delegation of reverse DNS. This is a good start for the re-work of the policy... but it sounds as if the acceptable justifications are wide and flexible enough to warrant the reasonable justification of 'I want to be portable and globally unique' - which in my opinion is all that you should need to desire to have your own allocation. There should be no requirement for Multi-homing (which by above seems their isn't) or being critical infrastructure (who defines that?), or even the size of the networks. I see a future where it will be very common for entities/individuals to have portable ranges that they do not wish to be tied to a particular ISP - IPv6 for life? I think that some of the justifications are so specific when a general 'I want to be unique and portable' seems to be good enough for the most part. ...Skeeve -- Skeeve Stevens, CEO eintellego Pty Ltd - The Networking Specialists skeeve at eintellego.net / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve www.linkedin.com/in/skeeve ; facebook.com/eintellego -- eintellego - The Experts that the Experts call - Juniper - HP Networking - Cisco - Arista - From Marla.Azinger at FTR.com Thu Sep 23 17:52:58 2010 From: Marla.Azinger at FTR.com (Azinger, Marla) Date: Thu, 23 Sep 2010 17:52:58 -0400 Subject: [arin-ppml] Updated 6rd proposal for ATLN conference Message-ID: <2E2FECEBAE57CC4BAACDE67638305F10488C312DBE@ROCH-EXCH1.corp.pvt> The 6rd proposal has been updated to satisfy ARIN staff questions and input Changes made: 1. relocated explanatory info into the Rational 2. Added justification guidelines to the Rational 3. Removed verbage that was unnessary and unfairly limiting to anyone wishing to use 6rd 4. Included explanation for contiguous theory 5. Added management of IP space details 6. Clarified the review and reclamation process 7. Added references and research support Revised version Template: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0 1. Policy Proposal Name: IPv6 for 6rd (RFC 5969) 2. Proposal Originator 1. name:Marla Azinger 2. email:marla.azinger at frontiercorp.com 3. telephone:585-413-9128 4. organization:Frontier Communications 1. name:Mark Townsley 2. email:townsley at cisco.com 3. telephone:+33-1-5804-3483 4. organization:Cisco Systems 1. name:Alain Durand 2. email:adurand at juniper.net 3. telephone:215-908-4848 4. organization:Juniper Networks 3. Proposal Version:1 4. Date:25 March 2010 5. Proposal type:NEW 6. Policy term:permanent 7. Policy statement: 6rd is an incremental method for Service Providers to deploy IPv6, defined in the IETF Standards Track RFC 5969. If you have IPv4 addresses then you automatically qualify for IPv6 space for 6rd. Upon receipt of a 6rd request, an appropriate additional IPv6 allocation will be made that supports 6rd to be counted as a separate & parallel deployment to IPv4 and native IPv6. There is no requirement to segregate address space requested under this policy from regular IPv6 Allocation Supernets. From a management perspective this address space is to be treated as regular IPv6 address space. While it is possible for an operator to transition to native IPv6 within the same address space used by 6rd, some operators may wish to keep native IPv6 users separate from 6rd users to permit optimization of aggregation. If an operator chooses to renumber users to an address space outside the 6rd aggregate when transitioning them to native IPv6, the 6rd allocation may be returned to ARIN when it is no longer in use. It is suggested that contiguous allocations be made to any prior existing ones in the event justification for more IPv6 address space exists when the organization transitions 6rd out of their network. Justification for use of IPv6 for 6rd will be reviewed after the first 3 years and reclaimed if it is not in use. After the first 3 years, any additional reviews will follow regular IPv6 policy. Requester will be exempt from returning all or a portion of the address space when 6rd is no longer used if they can show justification for need of the 6rd address space for other existing IPv6 addressing requirements be it native IPv6 or some other IPv6 network technology. 8. Rationale: 6rd is an incremental method for Service Providers to deploy IPv6, defined in the IETF Standards Track RFC 5969. 6rd has been used successfully by a number of service providers to deploy IPv6 based on automatic IPv6 prefix delegation and tunneling over existing IPv4 infrastructure. The chief advantage of this approach is that it deploys the service quickly while enabling the network administration to manage its deployment outlays, and ensures the correspondence between IPv4 and IPv6 routing. 6rd is distinct from other transition technologies such as 6to4 and Teredo in that it operates within the confines of a service provider network, allowing it to be managed by the service provider. 6rd is designed to be transparent to both the user and the rest of the Internet at large. To allow automatic prefix delegation to sites and stateless tunneling, 6rd utilizes a mapping scheme between an operator's IPv6 allocation and IPv4 address space. With a /32 allocation and non-contiguous IPv4 addressing plan, IPv6 deployment with 6rd is possible, but generally results in no more than a /64 to a subscriber site. A /28 allows the operator to delegate prefixes shorter than /64, allowing multiple /64 subnets within the home. When IPv4 addresses are known to be contiguous for the lifetime of the 6rd deployment, mechanisms exist for a more efficient mapping. This is most likely if the operator has deployed IPv4 NAPT technology within their network, and are addressing homes within a contiguous block of RFC 1918 space (e.g., 10/8). This example shows how the 6rd prefix is created based on a /28 IPv6 prefix using one of several non-contiguous global address ranges. This is a more realistic scenario of service providers in North America deploying IPv6 with 6rd today: SP IPv6 prefix: 2001:0DB0::/28 v4suffix-length: 32 (unable to exclude common bits due to non-contiguous IPv4 allocations) 6rd CE router IPv4 address: 192.0.2.1 6rd site IPv6 prefix: 2001:0DBC:0000:2010::/60 This example shows how the 6rd prefix is created based on a /32 IPv6 prefix using RFC1918 address space from 10.0.0.0/8. This example assumes the operator is facing IPv4 scarcity to the point it has deployed or is planning to deploy a layer of NAPT ("Carrier Grade NAT") within the service provider network and addressed its subscribers with private addresses accordingly: SP IPv6 prefix: 2001:0DB8::/32 v4suffix-length: 24 (from 10/8, first octet (10) is excluded from the encoding) 6rd CE router IPv4 address: 10.100.100.1 6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56 Justifications: Examples of how to display home networks using multiple subnets is accomplished by providing a network plan that involves the use of routing opposed to bridging. Such plans may involve the reduction of NAT, next-gen services, media types, separate L2 domains and more. The plan must simply show how the end user environment is not a single LAN subscriber. Supporting Research: 6rd is responsible for the largest production Ipv6 deployment today, supporting 4.5 million subscribers in France within a /26 that was granted by RIPE. This ISP previously had a /32, and went back and to RIPE for an additional /26. At least one other provider has deployed 6rd within a /27 that was granted recently for 6rd. A /24 was recently granted as well, likely for 6rd deployment. There are multiple providers in North America and around the world that have committed to delivering residential broadband service with 6rd, or are doing so today. The following RIPE report shows the affect 6rd has had in France, which accounts for the largest deployment in all of Europe or North America. http://labs.ripe.net/Members/emileaben/content-measuring-ipv6-web-clients-and-caching-resolvers-part-2-country-level-and-other-statistics "In Figure 2 (Western Europe), we see a native IPv6 client capability in France of over 4%. This is mainly caused by free.fr that accounts for 70% of the native IPv6 clients measured. Note that technically free.fr uses 6rd-tunneling, but externally that looks, feels and smells like native IPv6" 9. Timetable for implementation:Immediate -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- Template: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0 1. Policy Proposal Name: IPv6 for 6rd (RFC 5969) 2. Proposal Originator 1. name:Marla Azinger 2. email:marla.azinger at frontiercorp.com 3. telephone:585-413-9128 4. organization:Frontier Communications 1. name:Mark Townsley 2. email:townsley at cisco.com 3. telephone:+33-1-5804-3483 4. organization:Cisco Systems 1. name:Alain Durand 2. email:adurand at juniper.net 3. telephone:215-908-4848 4. organization:Juniper Networks 3. Proposal Version:1 4. Date:25 March 2010 5. Proposal type:NEW 6. Policy term:permanent 7. Policy statement: 6rd is an incremental method for Service Providers to deploy IPv6, defined in the IETF Standards Track RFC 5969. If you have IPv4 addresses then you automatically qualify for IPv6 space for 6rd. Upon receipt of a 6rd request, an appropriate additional IPv6 allocation will be made that supports 6rd to be counted as a separate & parallel deployment to IPv4 and native IPv6. There is no requirement to segregate address space requested under this policy from regular IPv6 Allocation Supernets. From a management perspective this address space is to be treated as regular IPv6 address space. While it is possible for an operator to transition to native IPv6 within the same address space used by 6rd, some operators may wish to keep native IPv6 users separate from 6rd users to permit optimization of aggregation. If an operator chooses to renumber users to an address space outside the 6rd aggregate when transitioning them to native IPv6, the 6rd allocation may be returned to ARIN when it is no longer in use. It is suggested that contiguous allocations be made to any prior existing ones in the event justification for more IPv6 address space exists when the organization transitions 6rd out of their network. Justification for use of IPv6 for 6rd will be reviewed after the first 3 years and reclaimed if it is not in use. After the first 3 years, any additional reviews will follow regular IPv6 policy. Requester will be exempt from returning all or a portion of the address space when 6rd is no longer used if they can show justification for need of the 6rd address space for other existing IPv6 addressing requirements be it native IPv6 or some other IPv6 network technology. 8. Rationale: 6rd is an incremental method for Service Providers to deploy IPv6, defined in the IETF Standards Track RFC 5969. 6rd has been used successfully by a number of service providers to deploy IPv6 based on automatic IPv6 prefix delegation and tunneling over existing IPv4 infrastructure. The chief advantage of this approach is that it deploys the service quickly while enabling the network administration to manage its deployment outlays, and ensures the correspondence between IPv4 and IPv6 routing. 6rd is distinct from other transition technologies such as 6to4 and Teredo in that it operates within the confines of a service provider network, allowing it to be managed by the service provider. 6rd is designed to be transparent to both the user and the rest of the Internet at large. To allow automatic prefix delegation to sites and stateless tunneling, 6rd utilizes a mapping scheme between an operator's IPv6 allocation and IPv4 address space. With a /32 allocation and non-contiguous IPv4 addressing plan, IPv6 deployment with 6rd is possible, but generally results in no more than a /64 to a subscriber site. A /28 allows the operator to delegate prefixes shorter than /64, allowing multiple /64 subnets within the home. When IPv4 addresses are known to be contiguous for the lifetime of the 6rd deployment, mechanisms exist for a more efficient mapping. This is most likely if the operator has deployed IPv4 NAPT technology within their network, and are addressing homes within a contiguous block of RFC 1918 space (e.g., 10/8). This example shows how the 6rd prefix is created based on a /28 IPv6 prefix using one of several non-contiguous global address ranges. This is a more realistic scenario of service providers in North America deploying IPv6 with 6rd today: SP IPv6 prefix: 2001:0DB0::/28 v4suffix-length: 32 (unable to exclude common bits due to non-contiguous IPv4 allocations) 6rd CE router IPv4 address: 192.0.2.1 6rd site IPv6 prefix: 2001:0DBC:0000:2010::/60 This example shows how the 6rd prefix is created based on a /32 IPv6 prefix using RFC1918 address space from 10.0.0.0/8. This example assumes the operator is facing IPv4 scarcity to the point it has deployed or is planning to deploy a layer of NAPT ("Carrier Grade NAT") within the service provider network and addressed its subscribers with private addresses accordingly: SP IPv6 prefix: 2001:0DB8::/32 v4suffix-length: 24 (from 10/8, first octet (10) is excluded from the encoding) 6rd CE router IPv4 address: 10.100.100.1 6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56 Justifications: Examples of how to display home networks using multiple subnets is accomplished by providing a network plan that involves the use of routing opposed to bridging. Such plans may involve the reduction of NAT, next-gen services, media types, separate L2 domains and more. The plan must simply show how the end user environment is not a single LAN subscriber. Supporting Research: 6rd is responsible for the largest production Ipv6 deployment today, supporting 4.5 million subscribers in France within a /26 that was granted by RIPE. This ISP previously had a /32, and went back and to RIPE for an additional /26. At least one other provider has deployed 6rd within a /27 that was granted recently for 6rd. A /24 was recently granted as well, likely for 6rd deployment. There are multiple providers in North America and around the world that have committed to delivering residential broadband service with 6rd, or are doing so today. The following RIPE report shows the affect 6rd has had in France, which accounts for the largest deployment in all of Europe or North America. http://labs.ripe.net/Members/emileaben/content-measuring-ipv6-web-clients-and-caching-resolvers-part-2-country-level-and-other-statistics "In Figure 2 (Western Europe), we see a native IPv6 client capability in France of over 4%. This is mainly caused by free.fr that accounts for 70% of the native IPv6 clients measured. Note that technically free.fr uses 6rd-tunneling, but externally that looks, feels and smells like native IPv6" 9. Timetable for implementation:Immediate From owen at delong.com Thu Sep 23 19:26:05 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 23 Sep 2010 16:26:05 -0700 Subject: [arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55) Message-ID: <28B1812C-FBCF-4EED-94CD-14FF2DBC4869@delong.com> Changes: 1. Set maximum reservation period to 24 months. This avoids creating a 4-year reservation by CIDR-rounding 36 month reservations. 2. Reduced minimum size for 4.10.4(b) to /28 These changes will make the policy more balanced and reduce the extent to which larger organizations could be disadvantaged relative to smaller smaller organizations if reservations have to be resized. The change to a 2-year system resolves an issue with the CIDR-Rounding where a 36-month reservation is mathematically guaranteed to become a 48-month reservation. The other alternative was to round-down instead of up which would have mathematically converted all reservations to 2 years. As such, a 2-year reservation system seemed the cleanest and most straightforward approach. Owen Draft Policy 2010-13: Permitted Uses of Space Reserved under NRPM 4.10 Proposal Originator: Owen DeLong, Chris Grundemann Proposal Version: 1.55 Date: 23 September 2010 Proposal type: modify Policy term: permanent Policy statement: Remove section 4.1.8 (Unmet requests) from the NRPM. Replace the text of section 4.10 in its entirety (including the name) with: 4.10 IPv4 Transition Pool Post IANA Regular Pool Depletion When ARIN receives its /8 IPv4 allocation from IANA under the global policy titled "Global Policy for the Allocation of the Remaining IPv4 Address Space" ratified by ICANN Board on 6 March, 2009, that /8 will form a dedicated pool to facilitate IPv6 Deployment. Addresses returned to ARIN and not subject to a regional or global transfer policy will be reserved for utilization in the transition pool. Allocations and assignments from this block must be justified by IPv6 transition requirements. ARIN will use their discretion in determining whether a particular application meets the spirit of this policy. 4.10.1 Addressing Plan Any organization wishing to receive IPv4 addresses through this policy must submit a detailed addressing plan for any request that is made containing the following: (a) Their addressing needs over the entire reservation period and (b) Methods of meeting all requirements (requirements are explained in section 4.10.4.) over the entire reservation period. 4.10.2 Reservation System Initially, all space assigned or allocated under this policy will be reserved in advance for a maximum period of 24 months, requests for shorter reservations will be accepted. The total reservation size will be rounded up to a CIDR bit boundary. Each organization's reservation amount will be divided into quarterly allotments. Allotments will be rounded up to a CIDR bit boundary. The final quarterly allotment will contain only the remaining space from the full reservation. An organization may request one reservation under each provision listed in section 4.10.4. Once a reservation has been satisfied, another may be requested. 4.10.2.1 Reservation Requests Prior to Initial ARIN Free Pool Depletion Reservations will be accepted from the time that this policy is adopted until the day that ARIN can no longer fill regular requests from space allocated to ARIN by IANA. At that time, if necessary, all reservations will be reduced by an equal amount to allow them to fit within the total space available in the transition pool. No reservation will be reduced lower than the minimum quarterly allotment for it's category. Each organization may decide whether to adjust the reservation period or the allotment size (within the stated range) when reservations are reduced. Organizations must make this decision within 30 days of announcement and may not alter their choice once made. Any space added to the transition pool during this time will cause a final recalculation of reservation sizes. Once all necessary adjustments are made, all reservations are guaranteed and the first quarterly allotment is issued to each org. 4.10.2.2 Reservation Requests Post ARIN Free Pool Depletion Reservation requests received after ARIN free pool depletion as defined in 4.10.2.1 will not be guaranteed. If approved, such requests will be placed in a queue. As space becomes available in the transition pool it will be used to provide allotments to organizations with reservations in the queue on a first-approved first-served basis. Partially filled allotments will remain at the front of the queue. 4.10.2.3 Abandonment of Reservation Any organization may abandon their remaining reservation at any time by informing ARIN of their desire to do so. Upon abandonment, the remaining space in the reservation will be returned to the transition pool. 4.10.3 Quarterly Requirements Organizations with approved reservations and address plans are entitled to quarterly allotments. In order to receive each additional allotment, an organization must submit evidence of compliance with the following sub-sections: (a) The most recent 4.10 allotment is at least 80% utilized. (b) All prior 4.10 allotments within the same 4.10.4 category are at least 90% utilized. (c) All utilization is permitted under the 4.10.4 category for which it was initially requested. For purposes of this computation, space received under each provision shall be considered separately if an organization has received resources through multiple provisions. If an organization does not meet all obligations in any given quarter, that organization shall not receive that quarter's allotment and shall have their reservation reduced by one quarterly allotment. If an organization does not meet all obligations for three consecutive quarters, that organization forfeits the remainder of their reserved block. Utilization requirements (a) may be delayed at ARIN's discretion. If an organization is using space received under 4.10 in a manner contrary to 4.10, that organization forfeits their remaining reservation and may have their entire allocation or assignment revoked. All 4.10. space forfeited, revoked or otherwise reclaimed shall be returned to the ARIN transition pool. 4.10.4 Specific types of transitional uses have specific requirements: (a) An ISP/LIR may request a block no smaller than a /25 nor larger than a /18 per quarter to be used to provide single IPv4 /32s to their customers which could justify a /28 or more of IPv4 under ARIN policies in effect at the time of IANA depletion. 1. No customer site may receive more than a single IPv4 /32 per 1,000 Internet connected hosts upto 8 /32s. 2. The customer site must not have any IPv4 addresses not issued under this policy. 3. The customer site must use the /32 to provide IPv4 connectivity for hosts which have IPv6 addresses with IPv6 connectivity to the ISP/LIR. 4. The ISP/LIR must demonstrate that it already provides IPv6 addressing and connectivity to at least one additional existing customer site for each /32 requested, up to 90% of all customer sites served (across all customers). 5. An ISP/LIR customer which is not large enough to qualify under this provision and has no unassigned IPv4 addresses may receive an appropriate number of /32s from their upstream provider for reassignment to their customers under the terms of 4.10.4(a). 6. A customer site which terminates multiple connections from the same provider on separate routers may qualify for one /32 per unique router with a direct connection to the provider, up to a total of 8 /32s. 7. The total space issued to all organizations under this provision shall not exceed an aggregate /9 or equivalent per /8 placed into the transition pool. (b) An ISP/LIR or End user organization may request a block no smaller than a /28 and no larger than a /18 per quarter to provide single IPv4 /32s to each physical server used to provide Internet reachable content. 1. Space issued under this provision is an assignment, not an allocation. An LIR may not distribute this space to their customers. 2. No server may receive more than a single IPv4 /32 under this provision. 3. The server must have IPv6 addresses with IPv6 connectivity (must be dual-stacked). 4. The receiving organization must demonstrate that it already provides IPv6 addressing and connectivity to at least one additional existing server (organizations which can show 100% dual stack are exempt from this requirement). 5. The receiving organization must IPv6 enable all of their content on the following schedule: + 25% of content IPv6 reachable within six months of receiving their first addresses under this policy + 50% of content IPv6 reachable within one year of receiving their first addresses under this policy + 75% of content IPv6 reachable within 18 months of receiving their first addresses under this policy + 90% of content IPv6 reachable within 24 months of receiving their first addresses under this policy 6. A network providing SSL terminations for applications or content acceleration may receive a /32 for each distinguished name by following all requirements in this provision, substituting "distinguished name" for "server." 7. Networks using these addresses for authoritative DNS servers can use 2 /32s per 1,000 authoritative domains served up to 128 /32s total per organization. 8. The total space issued to all organizations under this provision shall not exceed an aggregate /9 or equivalent per /8 placed into the transition pool. (c) An ISP/LIR or End user organization may request a block no smaller than a /29 and no larger than a /25 per quarter for purposes relevant to their ability to deploy IPv6. 1. Space issued under this provision is an assignment, not an allocation. An LIR may not distribute this space to their customers. 2. Space issued under this provision must be used to provide the required public IPv4 address(es) for transitional technologies operated by the recipient organization. Specific examples of permitted uses are: a. Large scale or "Carrier Grade" NAT b. NAT-PT c. DS-LITE/B4/AFTeR d. IVI e. DNS64 or other transitional DNS enablers f. Other technologies of similar purpose and scope. 3. A /10 from the final /8 shall be reserved for issuance under this provision. In no case shall any addresses from this /10 be issued for any purpose outside of 4.10.4(c). (d) Applications which would qualify for IPv4 under section 4.4 of the NRPM (critical infrastructure) may qualify for IPv4 space under this policy if they meet the following criteria: 1. The critical infrastructure to be numbered must also have IPv6 addresses and must provide all services provided on IPv4 over IPv6 on the same time table. 2. Assignments under this provision shall be the smallest technically feasible size for the critical infrastructure in question. 3. The total space assigned under this provision shall not exceed the equivalent of a /14.


Rationale:

The current terminology in section 4.10 is vague and could allow a variety of interpretations which could lead to allocations or assignments being made to ISPs intending to misuse the space for general deployment by using IPv6 overlay technologies as a "IPv6 deployments" requiring IPv4 space for transition. For example, the current policy could be interpreted to enable an ISP to require IPv4 addresses for all IPv6 customers to roll IPv6 out as 6rd to customers who would be otherwise unable to get IPv4 space. This is clearly outside of the original intent of the proposal which created 4.10 (6rd was not yet envisioned at the time that was written). This proposal seeks to clarify that intent and tighten up the requirements for organizations seeking to get space from this limited final resource so that it truly is available to facilitate transitional technologies.

Additionally, there are a number of community segments that are not well served by the original intent of 4.10 and several community members requested a mechanism for providing a certain amount of certainty with regards to obtaining space at the end. While it would be impossible to guarantee organizations all the space they need as runout is upon us, this policy seeks to provide a way for organizations to sign up for and receive a reservation from the final space proportionate to their need. The policy also includes guidelines intended to ensure that this vital community resource is given only to organizations working towards a smooth transition to IPv6 to the benefit of the full community.

In order to meet these needs, this policy has become very complex. It is an unfortunate artifact of the complex issue it seeks to address. A great deal of effort has been made to simplify the policy as much as possible, and, special thinks go out to several members of the community for their assistance in this matter.

One provision in this draft policy calls for utilization criteria which may be waived by ARIN staff discretion. The intent of this clause is to allow staff to avoid penalizing an organization for successful address conservation efforts.

Runout is upon us. IANA will run out of the IANA free pool and issue the last /8 this policy seeks to regulate before the next ARIN public policy meeting. If we are to make any attempt at fair distribution for the sake of IPv6 deployment, this is our final opportunity to do so outside of an emergency action by the ARIN board.

Timetable for implementation: immediate

For reference, here is the current text of 4.10

4.10 Dedicated IPv4 block to facilitate IPv6 Deployment

When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous /10 IPv4 block will be set aside and dedicated to facilitate IPv6 deployment. Allocations and assignments from this block must be justified by immediate IPv6 deployment requirements. Examples of such needs include: IPv4 addresses for key dual stack DNS servers, and NAT-PT or NAT464 translators. ARIN staff will use their discretion when evaluating justifications.

This block will be subject to a minimum size allocation of /28 and a maximum size allocation of /24. ARIN should use sparse allocation when possible within that /10 block.

In order to receive an allocation or assignment under this policy:
	1. the applicant may not have received resources under this policy in the preceding six months;
	2. previous allocations/assignments under this policy must continue to meet the justification requirements of this policy;
	3. previous allocations/assignments under this policy must meet the utilization requirements of end user assignments;
	4. the applicant must demonstrate that no other allocations or assignments will meet this need;
	5. on subsequent allocation under this policy, ARIN staff may require applicants to renumber out of previously allocated / assigned space under this policy in order to minimize non-contiguous allocations.

From info at arin.net  Fri Sep 24 11:59:19 2010
From: info at arin.net (ARIN)
Date: Fri, 24 Sep 2010 11:59:19 -0400
Subject: [arin-ppml] Draft Policy 2010-9: IPv6 for 6rd - revised
Message-ID: <4C9CCAD7.8070602@arin.net>

Draft Policy 2010-9
IPv6 for 6rd

2010-9 has been revised.

This draft policy is open for discussion on this mailing list and will
be on the agenda at the upcoming ARIN Public Policy Meeting in Atlanta.

2010-9 is below and available at:
https://www.arin.net/policy/proposals/2010_9.html

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy 2010-9
IPv6 for 6rd

Version/Date: 24 September 2010

Policy statement:

6rd is an incremental method for Service Providers to deploy IPv6,
defined in the IETF Standards Track RFC 5969. If you have IPv4 addresses
then you automatically qualify for IPv6 space for 6rd.  Upon receipt of
a 6rd request, an appropriate  additional IPv6 allocation will be made
that supports 6rd to be counted as a separate & parallel deployment to
IPv4 and native IPv6. There is no requirement to segregate address space
requested under this policy from regular IPv6 Allocation Supernets.
 From a management perspective  this address space is to be treated as
regular IPv6 address space.

While it is possible for an operator to transition to native IPv6 within
the same address space used by 6rd, some operators may wish to keep
native IPv6 users separate from 6rd users to permit optimization of
aggregation. If an operator chooses to renumber users to an address
space outside the 6rd aggregate when transitioning them to native IPv6,
the 6rd allocation may be returned to ARIN when it is no longer in use.
It is suggested that contiguous allocations be made to any prior
existing ones in the event justification for more IPv6 address space
exists when the organization transitions 6rd out of their network.

Justification for use of IPv6 for 6rd will be reviewed after the first 3
years and reclaimed if it is not in use. After the first 3 years, any
additional reviews will follow regular IPv6 policy. Requester will be
exempt from returning all or a portion of the address space when 6rd is
no longer  used if they can show justification for need of the 6rd
address space for other existing IPv6 addressing requirements be it
native IPv6 or some other IPv6 network technology.

Rationale:

6rd is an incremental method for Service Providers to deploy IPv6,
defined in the IETF Standards Track RFC 5969. 6rd has been used
successfully by a number of service providers to deploy IPv6 based on
automatic IPv6 prefix delegation and tunneling over existing IPv4
infrastructure. The chief advantage of this approach is that it deploys
the service quickly while enabling the network administration to manage
its deployment outlays, and ensures the correspondence between IPv4 and
IPv6 routing. 6rd is distinct from other transition technologies such as
6to4 and Teredo in that it operates within the confines of a service
provider network, allowing it to be managed by the service provider. 6rd
is designed to be transparent to both the user and the rest of the
Internet at large.

To allow automatic prefix delegation to sites and stateless tunneling,
6rd utilizes a mapping scheme between an operator's IPv6 allocation and
IPv4 address space. With a /32 allocation and non-contiguous IPv4
addressing plan, IPv6 deployment with 6rd is possible, but generally
results in no more than a /64 to a subscriber site. A /28 allows the
operator to delegate prefixes shorter than /64, allowing multiple /64
subnets within the home. When IPv4 addresses are known to be contiguous
for the lifetime of the 6rd deployment, mechanisms exist for a more
efficient mapping. This is most likely if the operator has deployed IPv4
NAPT technology within their network, and are addressing homes within a
contiguous block of RFC 1918 space (e.g., 10/8).

This example shows how the 6rd prefix is created based on a /28 IPv6
prefix using one of several non-contiguous global address ranges. This
is a more realistic scenario of service providers in North America
deploying IPv6 with 6rd today:

         SP IPv6 prefix: 2001:0DB0::/28
         v4suffix-length: 32 (unable to exclude common bits
                              due to non-contiguous IPv4 allocations)
         6rd CE router IPv4 address: 192.0.2.1
         6rd site IPv6 prefix: 2001:0DBC:0000:2010::/60

This example shows how the 6rd prefix is created based on a /32 IPv6
prefix using RFC1918 address space from 10.0.0.0/8.  This example
assumes the operator is facing IPv4 scarcity to the point it has
deployed or is planning to deploy a layer of NAPT ("Carrier Grade NAT")
within the service provider network and addressed its subscribers with
private addresses accordingly:

        SP IPv6 prefix: 2001:0DB8::/32
        v4suffix-length: 24 (from 10/8, first octet (10) is excluded
                             from the encoding)
        6rd CE router IPv4 address: 10.100.100.1
        6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56

Justifications: Examples of how to display home networks using multiple
subnets is accomplished by providing a network plan that involves the
use of routing opposed to bridging.  Such plans may involve the
reduction of NAT, next-gen services, media types, separate L2 domains
and more.  The plan must simply show how the end user environment is not
a single LAN subscriber.

Supporting Research: 6rd is responsible for the largest production Ipv6
deployment today, supporting 4.5 million subscribers in France within a
/26 that  was granted by RIPE. This ISP previously had a /32, and went
back and to RIPE for an additional /26. At least one other provider has
deployed 6rd within a /27 that  was granted recently for 6rd. A /24 was
recently granted as well, likely for 6rd deployment. There are multiple
providers in North America and around the world that have committed to
delivering residential broadband service with 6rd, or are doing so today.

The following RIPE report shows the affect 6rd has had in France, which
accounts for the largest deployment in all of Europe or North America.

http://labs.ripe.net/Members/emileaben/content-measuring-ipv6-web-clients-and-caching-resolvers-part-2-country-level-and-other-statistics

"In Figure 2 (Western Europe), we see a native IPv6 client capability in
France of over 4%. This is mainly caused by  free.fr  that accounts for
70% of the native IPv6 clients measured. Note that technically free.fr
uses 6rd-tunneling, but externally that looks, feels and smells like
native IPv6"

Timetable for implementation:Immediate





From bill at herrin.us  Fri Sep 24 12:33:42 2010
From: bill at herrin.us (William Herrin)
Date: Fri, 24 Sep 2010 12:33:42 -0400
Subject: [arin-ppml] Draft Policy 2010-9: IPv6 for 6rd - revised
In-Reply-To: <4C9CCAD7.8070602@arin.net>
References: <4C9CCAD7.8070602@arin.net>
Message-ID: 

On Fri, Sep 24, 2010 at 11:59 AM, ARIN  wrote:
> Draft Policy 2010-9
> IPv6 for 6rd

So basically you want to allocate and have ISPs announce a /28 into
BGP for the 6rd mechanism and then you want to allocate and have ISPs
announce another IPv6 prefix for their native v6 use?





-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: 
Falls Church, VA 22042-3004


From cgrundemann at gmail.com  Fri Sep 24 15:03:15 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Fri, 24 Sep 2010 13:03:15 -0600
Subject: [arin-ppml] Draft Policy 2010-14: Standardize IP Reassignment
 Registration Requirements
In-Reply-To: <4C98BCE5.30308@arin.net>
References: <4C61C448.7090403@arin.net>
	<4C98BCE5.30308@arin.net>
Message-ID: 

On Tue, Sep 21, 2010 at 08:10, ARIN  wrote:
>
> A. ARIN Staff Comments
>
> ? This proposal would replace the 3 existing qualifying criteria of the
> Cable Policy (NRPM section 4) with the single criterion of must
> show >50% utilization.
> ?o It is staff?s observation that the existing cable policy works well
> for cable providers as is and staff cannot discern what problem this
> section of the proposal is attempting to solve.

I tried to answer this concern in the rationale and I think you
captured the purpose quite well in your bullet below: "it would likely
be beneficial for many of ARIN?s customers who share very similar
technologies to the cable industry, but have never been able to apply
under the cable policy (technologies like dsl, fiber to the home,
etc.)."

Additionally, the current 4.2.6. is laced with SWIP/RWHOIS
requirements and I believe that it makes more sense to consolidate all
registration requirements into one section, to enhance clarity within
the NRPM.

> ?o The current cable policy requires 80% of the ISP?s address space to
> be provisioned to hardware and to be reassigned, with a 50 ? 80%
> utilization rate. This new proposal removes the 80% requirement, which
> would allow a provider to provision and reassign only 50% of their most
> recent allocation. The result seems to be lowered efficiency of overall
> address space usage.
> ?o The text in this section is somewhat unclear and confusing as written.

My intent was not to lower the efficiency but only to simplify the
policy. Current policy already holds all ISPs to an 80% utilization
requirement for subsequent allocations (see 4.2.4.1. Utilization
percentage (80%)). Thus, I found re-stating the 80% requirement
somewhat redundant and unnecessary and chose to only specify the
exception to that rule (>50% utilization on the most recent
allocation).

If this is unclear, I think that it can be easily cleared up with a
minor editorial change after the meeting (since the text is already
frozen now).

> ? Because this proposal would apply to all residential dynamic
> addressing pools (in addition to cable), it would likely be beneficial
> for many of ARIN?s customers who share very similar technologies to the
> cable industry, but have never been able to apply under the cable policy
> (technologies like dsl, fiber to the home, etc.).
> ? This proposal provides a well-defined explanation of what a
> residential customer is and will be beneficial to both the community and
> to the staff. ?The existing definition of ??residential customer? has
> caused some confusion for customers.

Thank you for the great feedback (as always)!

~Chris

> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>

-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org


From owen at delong.com  Fri Sep 24 15:11:22 2010
From: owen at delong.com (Owen DeLong)
Date: Fri, 24 Sep 2010 12:11:22 -0700
Subject: [arin-ppml] Draft Policy 2010-9: IPv6 for 6rd - revised
In-Reply-To: 
References: <4C9CCAD7.8070602@arin.net>
	
Message-ID: 


On Sep 24, 2010, at 9:33 AM, William Herrin wrote:

> On Fri, Sep 24, 2010 at 11:59 AM, ARIN  wrote:
>> Draft Policy 2010-9
>> IPv6 for 6rd
> 
> So basically you want to allocate and have ISPs announce a /28 into
> BGP for the 6rd mechanism and then you want to allocate and have ISPs
> announce another IPv6 prefix for their native v6 use?
> 
I believe the actual intent is to make it possible for ISPs that already have
native allocations to still get /28s for 6rd use if they need them.

Owen



From bill at herrin.us  Sat Sep 25 13:10:46 2010
From: bill at herrin.us (William Herrin)
Date: Sat, 25 Sep 2010 13:10:46 -0400
Subject: [arin-ppml] I Oppose 2010-9: IPv6 for 6rd as written.
Message-ID: 

On Fri, Sep 24, 2010 at 11:59 AM, ARIN  wrote:
> Draft Policy 2010-9
> IPv6 for 6rd
>
> Version/Date: 24 September 2010
>
> Policy statement:
>
> 6rd is an incremental method for Service Providers to deploy IPv6,
> defined in the IETF Standards Track RFC 5969. If you have IPv4 addresses
> then you automatically qualify for IPv6 space for 6rd. ?Upon receipt of
> a 6rd request, an appropriate ?additional IPv6 allocation will be made
> that supports 6rd to be counted as a separate & parallel deployment to
> IPv4 and native IPv6. There is no requirement to segregate address space
> requested under this policy from regular IPv6 Allocation Supernets.
> From a management perspective ?this address space is to be treated as
> regular IPv6 address space.
>
> While it is possible for an operator to transition to native IPv6 within
> the same address space used by 6rd, some operators may wish to keep
> native IPv6 users separate from 6rd users to permit optimization of
> aggregation. If an operator chooses to renumber users to an address
> space outside the 6rd aggregate when transitioning them to native IPv6,
> the 6rd allocation may be returned to ARIN when it is no longer in use.
> It is suggested that contiguous allocations be made to any prior
> existing ones in the event justification for more IPv6 address space
> exists when the organization transitions 6rd out of their network.
>
> Justification for use of IPv6 for 6rd will be reviewed after the first 3
> years and reclaimed if it is not in use. After the first 3 years, any
> additional reviews will follow regular IPv6 policy. Requester will be
> exempt from returning all or a portion of the address space when 6rd is
> no longer ?used if they can show justification for need of the 6rd
> address space for other existing IPv6 addressing requirements be it
> native IPv6 or some other IPv6 network technology.


After careful consideration, I OPPOSE proposal 2010-9 as written.
Although I agree that 6rd use should justify an IPv6 allocation, I
think this proposal should be deferred until the Spring and thoroughly
rewritten.

My reasons are:

First, 2010-9 as written more or less guarantees an IPv6 /28 to ALL
CURRENT IPv4 REGISTRANTS:

"If you have IPv4 addresses then you automatically qualify for IPv6
space for 6rd. [...] A /28 allows the operator to delegate prefixes
shorter than /64, allowing multiple /64 subnets within the home."

Second, the proposal needs major wordsmithing. The language is too
opaque, making it difficult to tease out how ARIN is supposed to
evaluate IPv6 applications justified by an intent to use 6rd. It
should be rewritten with phrases like "ARIN shall," using far fewer
words per paragraph and with the addition of short headings for
clarity.

Third, the proposal encourages ARIN to allocate /28's in addition to
the ISP's native IPv6 assignment, adding expensive consumption to the
routing table. If the intent is to facilitate 6rd deployments in this
fashion then the policy should explicitly encourage ISPs to accept /27
allocations so that they may employ both 6rd and native IPv6 within a
single contiguous allocation.

Fourth, except for the handful of gigantic ISPs managing hundreds of
IPv4 blocks, mapping IPv4 into 32 bits of IPv6 address space is
disgustingly wasteful. By configuring one 6rd handler for each IPv4
allocation held, nearly every ISP can easily employ 6rd within 24 bits
or less. That allows it to fit entirely inside their /32 allocation,
even when attaching the suggested /60 or more even more addresses to
every IPv4 endpoint.

Finally, noting 6rd's use of the 6to4 protocol and addresses announced
via BGP, I want to take a moment to say, "I told you so:"
http://lists.arin.net/pipermail/arin-ppml/2007-July/007965.html

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: 
Falls Church, VA 22042-3004


From owen at delong.com  Sat Sep 25 14:18:44 2010
From: owen at delong.com (Owen DeLong)
Date: Sat, 25 Sep 2010 11:18:44 -0700
Subject: [arin-ppml] I Oppose 2010-9: IPv6 for 6rd as written.
In-Reply-To: 
References: 
Message-ID: 

> 
> After careful consideration, I OPPOSE proposal 2010-9 as written.
> Although I agree that 6rd use should justify an IPv6 allocation, I
> think this proposal should be deferred until the Spring and thoroughly
> rewritten.
> 
> My reasons are:
> 
> First, 2010-9 as written more or less guarantees an IPv6 /28 to ALL
> CURRENT IPv4 REGISTRANTS:
> 
> "If you have IPv4 addresses then you automatically qualify for IPv6
> space for 6rd. [...] A /28 allows the operator to delegate prefixes
> shorter than /64, allowing multiple /64 subnets within the home."
> 
You say that like it's somehow a bad thing.

In the first /12 per region, there's more than enough space to give every
single active ASN two /28s. Even if the uptake on this proposal was
100% and every ASN currently in the global table (world wide) took one
from ARIN, it would only consume 1/2 of that first /12.

I'm simply not seeing a problem with using /28s this way?

> Second, the proposal needs major wordsmithing. The language is too
> opaque, making it difficult to tease out how ARIN is supposed to
> evaluate IPv6 applications justified by an intent to use 6rd. It
> should be rewritten with phrases like "ARIN shall," using far fewer
> words per paragraph and with the addition of short headings for
> clarity.
> 
I can't disagree with this, and, I would support future policy to improve
the situation. However, I think the language here is adequate to at least
start meeting the needs of providers that want to deploy 6rd and I think
it is more important that ARIN not pose an impediment to this process,
especially between now and IANA depletion than to have ideal
wording.

> Third, the proposal encourages ARIN to allocate /28's in addition to
> the ISP's native IPv6 assignment, adding expensive consumption to the
> routing table. If the intent is to facilitate 6rd deployments in this
> fashion then the policy should explicitly encourage ISPs to accept /27
> allocations so that they may employ both 6rd and native IPv6 within a
> single contiguous allocation.
> 
In fact, I would proffer that a single /28 would allow ISPs to do both
6rd _AND_ native IPv6 within the same prefix. No need to expand
it to a /27.

It's important that providers that already have partial deployments with
IPv6 be able to get an additional /28 for 6rd. I don't think we should be
giving providers that get 6rd space additional space beyond that /28.
I would support a proposal resolving this at a future meeting, but, again
for now, I think this tradeoff is acceptable vs. the cost of blocking 6rd
deployment between now and IANA depletion.

> Fourth, except for the handful of gigantic ISPs managing hundreds of
> IPv4 blocks, mapping IPv4 into 32 bits of IPv6 address space is
> disgustingly wasteful. By configuring one 6rd handler for each IPv4
> allocation held, nearly every ISP can easily employ 6rd within 24 bits
> or less. That allows it to fit entirely inside their /32 allocation,
> even when attaching the suggested /60 or more even more addresses to
> every IPv4 endpoint.
> 
Really? Who cares? As long as we set it up so that they are expected
to fill the "holes" with traditional IPv6 reallocations and reassignments,
what is the problem? As I stated, this would still constitute such a
small consumption of address space that I just don't see the benefit
to making it  an issue.


Owen



From bill at herrin.us  Sat Sep 25 16:46:51 2010
From: bill at herrin.us (William Herrin)
Date: Sat, 25 Sep 2010 16:46:51 -0400
Subject: [arin-ppml] I Oppose 2010-9: IPv6 for 6rd as written.
In-Reply-To: 
References: 
	
Message-ID: 

On Sat, Sep 25, 2010 at 2:18 PM, Owen DeLong  wrote:
>> After careful consideration, I OPPOSE proposal 2010-9 as written.
>> Although I agree that 6rd use should justify an IPv6 allocation, I
>> think this proposal should be deferred until the Spring and thoroughly
>> rewritten.
>
>> First, 2010-9 as written more or less guarantees an IPv6 /28 to ALL
>> CURRENT IPv4 REGISTRANTS:
>
>You say that like it's somehow a bad thing.

Owen,

It worries me that we've barely started to deploy IPv6 yet we keep
finding ways to consume fractions of this 128-bit space that are
noticeable even in the first 32 bits. Looking back with 20/20
hindsight, early burn noticeable in the first quarter of the bits is
widely recognized as a bad mistake with IPv4.


>> Third, the proposal encourages ARIN to allocate /28's in addition to
>> the ISP's native IPv6 assignment, adding expensive consumption to the
>> routing table. If the intent is to facilitate 6rd deployments in this
>> fashion then the policy should explicitly encourage ISPs to accept /27
>> allocations so that they may employ both 6rd and native IPv6 within a
>> single contiguous allocation.
>>
> In fact, I would proffer that a single /28 would allow ISPs to do both
> 6rd _AND_ native IPv6 within the same prefix. No need to expand
> it to a /27.

If you accept the premise that it's reasonable to map all 32 bits of
IPv4 address space into 6rd's dynamic tunnelling and end up with a /60
hanging off each IPv4 decapsulator then from a purely technical
viewpoint you CAN'T use native IPv6 and 6rd in the same /28 at the
same time. Read the RFC. Space usable for native IPv6 has to be
entirely outside the contiguous prefix you've mapped into 6rd, so if
you're mapping all 32 bits and delivering a /60, then 6rd consumes the
whole /28.

Hence if you also want to do native IPv6 in the same contiguous prefix
you have to start with a /27 or shorter from which a /28 is dedicated
to 6rd.


> It's important that providers that already have partial deployments with
> IPv6 be able to get an additional /28 for 6rd. I don't think we should be
> giving providers that get 6rd space additional space beyond that /28.
> I would support a proposal resolving this at a future meeting, but, again
> for now, I think this tradeoff is acceptable vs. the cost of blocking 6rd
> deployment between now and IANA depletion.

If 6rd deployment was blocked, I might agree with you. It isn't. As
6rd is designed, only the lower bits of each of the ISP's IPv4
allocations need be programmed into 6rd, allowing it to be usefully
employed within several fractions of the /32 allocation ISPs can
already easily get.

For that matter, if this proposal was less defective I might agree
with fixing it later. But the policy text is too poorly crafted.
However interesting the idea, opaque and ambiguous text makes for bad
policy.


>> Fourth, except for the handful of gigantic ISPs managing hundreds of
>> IPv4 blocks, mapping IPv4 into 32 bits of IPv6 address space is
>> disgustingly wasteful. By configuring one 6rd handler for each IPv4
>> allocation held, nearly every ISP can easily employ 6rd within 24 bits
>> or less. That allows it to fit entirely inside their /32 allocation,
>> even when attaching the suggested /60 or more even more addresses to
>> every IPv4 endpoint.
>>
> Really? Who cares? As long as we set it up so that they are expected
> to fill the "holes" with traditional IPv6 reallocations and reassignments,
> what is the problem?

Read the RFC. Native IPv6 use in the defined 6rd block can only
commence AFTER 6rd use stops. The technology doesn't facilitate
"filling the holes."

Regards,
Bill Herrin




-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: 
Falls Church, VA 22042-3004


From bill at herrin.us  Sat Sep 25 18:04:46 2010
From: bill at herrin.us (William Herrin)
Date: Sat, 25 Sep 2010 18:04:46 -0400
Subject: [arin-ppml] I Oppose 2010-9: IPv6 for 6rd as written.
In-Reply-To: 
References: 
	
Message-ID: 

On Sat, Sep 25, 2010 at 2:18 PM, Owen DeLong  wrote:
>> Second, the proposal needs major wordsmithing. The language is too
>> opaque, making it difficult to tease out how ARIN is supposed to
>> evaluate IPv6 applications justified by an intent to use 6rd. It
>> should be rewritten with phrases like "ARIN shall," using far fewer
>> words per paragraph and with the addition of short headings for
>> clarity.
>>
> I can't disagree with this, and, I would support future policy to improve
> the situation. However, I think the language here is adequate to at least
> start meeting the needs of providers that want to deploy 6rd and I think
> it is more important that ARIN not pose an impediment to this process,
> especially between now and IANA depletion than to have ideal
> wording.

Owen,

Although I'm still not sure I'd support it, it ought to be easy enough
to rewrite the proposal as clear policy adding a couple simple
safeguards:

"Internet Service Providers holding at least two discontiguous ARIN
IPv4 allocations shall be eligible to receive up to a /27 IPv6
allocation for the purpose of deploying RFC 5969 6RD by mapping the
32-bit IPv4 address into a /28 and hanging a /60 off each potential
6rd decapsulator."

Boom. Done.

The /27 allows native IPv6 to exist alongside the 6rd /28 within the
same contiguous allocation.

Text is now limited to ISPs, not "everybody."

Now limited to ISPs holding at least two ARIN allocations. Any
registrant with just one address block can employ 6rd consuming far
less than 32 bits just as easily as they can use 32 bits.

Regards,
Bill Herrin





-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: 
Falls Church, VA 22042-3004


From owen at delong.com  Sat Sep 25 21:53:02 2010
From: owen at delong.com (Owen DeLong)
Date: Sat, 25 Sep 2010 18:53:02 -0700
Subject: [arin-ppml] I Oppose 2010-9: IPv6 for 6rd as written.
In-Reply-To: 
References: 
	
	
Message-ID: <3492F483-E435-4C29-8B9D-B50D67A0BB5B@delong.com>


On Sep 25, 2010, at 1:46 PM, William Herrin wrote:

> On Sat, Sep 25, 2010 at 2:18 PM, Owen DeLong  wrote:
>>> After careful consideration, I OPPOSE proposal 2010-9 as written.
>>> Although I agree that 6rd use should justify an IPv6 allocation, I
>>> think this proposal should be deferred until the Spring and thoroughly
>>> rewritten.
>> 
>>> First, 2010-9 as written more or less guarantees an IPv6 /28 to ALL
>>> CURRENT IPv4 REGISTRANTS:
>> 
>> You say that like it's somehow a bad thing.
> 
> Owen,
> 
> It worries me that we've barely started to deploy IPv6 yet we keep
> finding ways to consume fractions of this 128-bit space that are
> noticeable even in the first 32 bits. Looking back with 20/20
> hindsight, early burn noticeable in the first quarter of the bits is
> widely recognized as a bad mistake with IPv4.
> 
Noticeable is, I guess open to interpretation...

In 128 bits, a /28 is much less noticeable than a /8 in IPv4...

I don't think that 0.00000037% is nearly as noticeable as you appear to
think it is.

On the other hand, 0.39% would strike me as a much more noticeable
portion of the address space. (an IPv4 /8).

Put another way, if nobody had more than a /28 of IPv4 space, we probably
wouldn't be anywhere near runout today. However, in IPv4, a /28 is nowhere
near enough space to number even so much as an early adopter's house,
let alone a significant enterprise. In IPv6, however, it's probably enough
to number all but the top 1% of organizations.

> 
>>> Third, the proposal encourages ARIN to allocate /28's in addition to
>>> the ISP's native IPv6 assignment, adding expensive consumption to the
>>> routing table. If the intent is to facilitate 6rd deployments in this
>>> fashion then the policy should explicitly encourage ISPs to accept /27
>>> allocations so that they may employ both 6rd and native IPv6 within a
>>> single contiguous allocation.
>>> 
>> In fact, I would proffer that a single /28 would allow ISPs to do both
>> 6rd _AND_ native IPv6 within the same prefix. No need to expand
>> it to a /27.
> 
> If you accept the premise that it's reasonable to map all 32 bits of
> IPv4 address space into 6rd's dynamic tunnelling and end up with a /60
> hanging off each IPv4 decapsulator then from a purely technical
> viewpoint you CAN'T use native IPv6 and 6rd in the same /28 at the
> same time. Read the RFC. Space usable for native IPv6 has to be
> entirely outside the contiguous prefix you've mapped into 6rd, so if
> you're mapping all 32 bits and delivering a /60, then 6rd consumes the
> whole /28.
> 
I have read the RFC.. However, you don't actually have to map all of
IPv4.. You just need an easy way to map all of the IPv4 that is delegated
to you. If, for example, a provider had 5/8, 10/8, 15/8, and 20/8, there is
no reason they could not be delegated 2000:db80::/28 and use it in the
following manner:

2000:db80:0000::/48 - 2000:db80:4fff::/48 - Native IPv6 assignments
2000:db80:5000::/48 - 2000:db80:5fff::/48 - Mapped 5/8 6rd space
2000:db80:6000::/48 - 2000:db80:9fff::/48 - Native IPv6 assignments
2000:db80:a000::/48 - 2000:db80:afff::/48 - Mapped 10/8 6rd space
2000:db80:b000::/48 - 2000:db80:efff::/48 - Native IPv6 assignments
2000:db80:f000::/48 - 2000:db80:ffff::/48 - Mapped 15/8 6rd space
2000:db81::/48 - 2000:db81:3fff::/48 - Native IPv6 assignments
2000:db81:4000::/48 - 2001:db81:4fff::/48 - Mapped 20/8 6rd space
2001:db81:5000::/48 - 2001:db8f:ffff::/48 - Native IPv6 assignments

Frankly, if it weren't for the routing table implications, the easy way
to do this from an IP policy perspective, would be to allocate a single
IPv6 /28 to 6rd and have all providers simply mirror their IPv4 from
that prefix. This, however, is an obviously bad idea from a routing
perspective since it would create ~300,000 unnecessary IPv6 routes.
Therefore, I think it makes much more sense to allocate a /28 to
each provider, allowing them to fill in the holes in their v4 map with
native IPv6 usage.

> Hence if you also want to do native IPv6 in the same contiguous prefix
> you have to start with a /27 or shorter from which a /28 is dedicated
> to 6rd.
> 
Not so much, no, you don't... See above.

> 
>> It's important that providers that already have partial deployments with
>> IPv6 be able to get an additional /28 for 6rd. I don't think we should be
>> giving providers that get 6rd space additional space beyond that /28.
>> I would support a proposal resolving this at a future meeting, but, again
>> for now, I think this tradeoff is acceptable vs. the cost of blocking 6rd
>> deployment between now and IANA depletion.
> 
> If 6rd deployment was blocked, I might agree with you. It isn't. As
> 6rd is designed, only the lower bits of each of the ISP's IPv4
> allocations need be programmed into 6rd, allowing it to be usefully
> employed within several fractions of the /32 allocation ISPs can
> already easily get.
> 
This is true, except for the providers serving the largest user bases
where mapping the lower bits doesn't actually do the trick.

I think that blocking 6rd for that large a portion of the population
is effectively blocking 6rd in a pretty meaningful way. To put it in
perspective, it's way more noticeable a fraction of total users than,
say 0.00000037%.

> For that matter, if this proposal was less defective I might agree
> with fixing it later. But the policy text is too poorly crafted.
> However interesting the idea, opaque and ambiguous text makes for bad
> policy.
> 
Again, as I said, it's not ideal. Some of it can probably get fixed by the
AC between the meeting and last call. (constructive suggestions for
improvement welcome). However, I still think that the policy is far
too urgent to allow it to languish past IPv4 runout. That, sir, would be
very bad policy.
> 
>>> Fourth, except for the handful of gigantic ISPs managing hundreds of
>>> IPv4 blocks, mapping IPv4 into 32 bits of IPv6 address space is
>>> disgustingly wasteful. By configuring one 6rd handler for each IPv4
>>> allocation held, nearly every ISP can easily employ 6rd within 24 bits
>>> or less. That allows it to fit entirely inside their /32 allocation,
>>> even when attaching the suggested /60 or more even more addresses to
>>> every IPv4 endpoint.
>>> 
>> Really? Who cares? As long as we set it up so that they are expected
>> to fill the "holes" with traditional IPv6 reallocations and reassignments,
>> what is the problem?
> 
> Read the RFC. Native IPv6 use in the defined 6rd block can only
> commence AFTER 6rd use stops. The technology doesn't facilitate
> "filling the holes."
> 
Technically, the only reason I see for this in the RFC is actually the need to
delay usage of those portions that might collide with future IPv4 allocations
or assignments to the organization in question. While the RFC doesn't
spell this out particularly well (speaking of opaque language), it's really
not that hard to use 6rd space in the manner I described above without
breaking either technology.

Additionally, there's enough IPv4 bogon and martian space that
could be used for your early native IPv6 portions that I regard this as largely
unnecessary, especially given the relatively short time frame to IPv4 runout.

Once an organization stops receiving new IPv4 allocations/assignments, there's
really no need to worry about the threat of future collisions.

Owen



From owen at delong.com  Sat Sep 25 21:55:51 2010
From: owen at delong.com (Owen DeLong)
Date: Sat, 25 Sep 2010 18:55:51 -0700
Subject: [arin-ppml] I Oppose 2010-9: IPv6 for 6rd as written.
In-Reply-To: 
References: 
	
	
Message-ID: <55F1F05C-6896-4022-9B2B-F634D0219A1D@delong.com>

I would support that change and would support the idea of making
it at the AC level after the meeting before last call. I think it is minor
and in line with the original intent of the policy.

Not wild about moving away from nibble boundaries, but, this is one
case where I don't see much impact from the issue.


Owen

On Sep 25, 2010, at 3:04 PM, William Herrin wrote:

> On Sat, Sep 25, 2010 at 2:18 PM, Owen DeLong  wrote:
>>> Second, the proposal needs major wordsmithing. The language is too
>>> opaque, making it difficult to tease out how ARIN is supposed to
>>> evaluate IPv6 applications justified by an intent to use 6rd. It
>>> should be rewritten with phrases like "ARIN shall," using far fewer
>>> words per paragraph and with the addition of short headings for
>>> clarity.
>>> 
>> I can't disagree with this, and, I would support future policy to improve
>> the situation. However, I think the language here is adequate to at least
>> start meeting the needs of providers that want to deploy 6rd and I think
>> it is more important that ARIN not pose an impediment to this process,
>> especially between now and IANA depletion than to have ideal
>> wording.
> 
> Owen,
> 
> Although I'm still not sure I'd support it, it ought to be easy enough
> to rewrite the proposal as clear policy adding a couple simple
> safeguards:
> 
> "Internet Service Providers holding at least two discontiguous ARIN
> IPv4 allocations shall be eligible to receive up to a /27 IPv6
> allocation for the purpose of deploying RFC 5969 6RD by mapping the
> 32-bit IPv4 address into a /28 and hanging a /60 off each potential
> 6rd decapsulator."
> 
> Boom. Done.
> 
> The /27 allows native IPv6 to exist alongside the 6rd /28 within the
> same contiguous allocation.
> 
> Text is now limited to ISPs, not "everybody."
> 
> Now limited to ISPs holding at least two ARIN allocations. Any
> registrant with just one address block can employ 6rd consuming far
> less than 32 bits just as easily as they can use 32 bits.
> 
> Regards,
> Bill Herrin
> 
> 
> 
> 
> 
> -- 
> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
> 3005 Crane Dr. ...................... Web: 
> Falls Church, VA 22042-3004



From Wesley.E.George at sprint.com  Mon Sep 27 12:31:33 2010
From: Wesley.E.George at sprint.com (George, Wes E [NTK])
Date: Mon, 27 Sep 2010 11:31:33 -0500
Subject: [arin-ppml] I Oppose 2010-9: IPv6 for 6rd as written.
In-Reply-To: 
References: 
Message-ID: 

I do not support this policy as written either.
I echo Bill's comments below, at least for the first 3 issues that he raises. I'm not totally convinced of the other few regarding addressing efficiency or lack thereof, but I think that there's value in discussing it further.

Also, I think that this proposal would be much stronger if it cited one or more examples of providers who have tried to request additional space from ARIN for this purpose and been denied based on not meeting criteria for additional space according to the current NRPM. Otherwise, I need some convincing that we're solving a problem that actually exists vs policy for policy's sake. Free.FR is cited as an example, but to my knowledge no similar policy carving out special permission for providers that wish to deploy 6RD exists at RIPE, nor is there a similar policy update proposal on the table. Alternatively, the text could point to differences between ARIN NRPM and RIPE IPv6 Address Allocation and Assignment policy that would lead to a request for space for 6RD being approved by RIPE but not ARIN.

Further, I would still like this proposal to be more generic in nature instead of specific to 6RD, as I don't want to see us writing a new policy for every new transition technology that someone wants to implement. People are writing new ones or variants on existing ones nearly every IETF meeting, so if even some of them stick and get implemented, it's not scalable to write policies based on a single implementation, especially as time becomes of the essence post IPv4-exhaustion. As I said before, I'd support something that points out 6RD as an example where RIPE policy would permit and ARIN would not and suggested changes to the necessary wording to fix this, or something that allows for a more generic "allocation to implement a transition technology" with requirements to justify why a second allocation is required, and some of the language in this current proposal regarding temporary assignment, rejustification and reclamation.

Thanks
Wes George, Sprint

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin
Sent: Saturday, September 25, 2010 1:11 PM
To: arin-ppml at arin.net
Subject: [arin-ppml] I Oppose 2010-9: IPv6 for 6rd as written.

On Fri, Sep 24, 2010 at 11:59 AM, ARIN  wrote:
> Draft Policy 2010-9
> IPv6 for 6rd
>
> Version/Date: 24 September 2010

[[WEG]] snip

After careful consideration, I OPPOSE proposal 2010-9 as written.
Although I agree that 6rd use should justify an IPv6 allocation, I
think this proposal should be deferred until the Spring and thoroughly
rewritten.

My reasons are:

First, 2010-9 as written more or less guarantees an IPv6 /28 to ALL
CURRENT IPv4 REGISTRANTS:

"If you have IPv4 addresses then you automatically qualify for IPv6
space for 6rd. [...] A /28 allows the operator to delegate prefixes
shorter than /64, allowing multiple /64 subnets within the home."

Second, the proposal needs major wordsmithing. The language is too
opaque, making it difficult to tease out how ARIN is supposed to
evaluate IPv6 applications justified by an intent to use 6rd. It
should be rewritten with phrases like "ARIN shall," using far fewer
words per paragraph and with the addition of short headings for
clarity.

Third, the proposal encourages ARIN to allocate /28's in addition to
the ISP's native IPv6 assignment, adding expensive consumption to the
routing table. If the intent is to facilitate 6rd deployments in this
fashion then the policy should explicitly encourage ISPs to accept /27
allocations so that they may employ both 6rd and native IPv6 within a
single contiguous allocation.
[[WEG]] snip

Regards,
Bill Herrin



This e-mail may contain Sprint Nextel proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.



From bill at herrin.us  Mon Sep 27 13:27:36 2010
From: bill at herrin.us (William Herrin)
Date: Mon, 27 Sep 2010 13:27:36 -0400
Subject: [arin-ppml] I Oppose 2010-12: IPv6 Subsequent Allocation
Message-ID: 

>Draft Policy 2010-12
>IPv6 Subsequent Allocation
>
>Version/Date: 20 July 2010
>
>Policy statement:
>
>Modify 6.5.2.1 Subsequent allocation criteria. ADD the following
>sentence: Subsequent allocations will also be considered for
>transitional technologies that cannot be accommodated by,
>nor were accounted for, under the initial allocation.
>
>Justification for the subsequent subnet size will be based
>on the plan and technology provided. Justification for these
>allocations will be reviewed every 3 years and reclaimed
>if it is not in use. Requester will be exempt from returning
>all or a portion of the address space if they can show
>justification for need of this allocation for other existing
>IPv6 addressing requirements be it Native V6 or some
>other V6 network technology.

After careful consideration, I OPPOSE draft policy 2010-12 as written.
Although I agree in principle that subsequent IPv6 allocations at this
early stage should be driven more by recognized addressing needs than
competent consumption of the prior allocation, this particular
proposal needs more work.

2010-12 offers no guidance as to how ARIN staff is supposed to sort
reasonable requests for transition addresses from unreasonable ones.
Indeed, as written a small ISP with a pair of /20 IPv4 allocations
could request a /15 of IPv6 addresses for the purpose of hanging a /48
off each of their IPv4 address using 32-bit mapped 6rd in one /16 with
a second /16 left over for native IPv6. No language in the resulting
ARIN policy would suggest that such an enormous request is in any
respect improper. Indeed, the policy would fail to support ARIN staff
attempting to deny such a request.

Accordingly, I can not support proposal 2010-12 until it has been
rewritten in a form that offers guidance to staff as to how requests
are to be evaluated and places appropriately conservative safeguards
on the both the number of subsequent allocations and the raw count of
allocable addresses.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: 
Falls Church, VA 22042-3004


From info at arin.net  Mon Sep 27 16:02:34 2010
From: info at arin.net (ARIN)
Date: Mon, 27 Sep 2010 16:02:34 -0400
Subject: [arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55)
Message-ID: <4CA0F85A.20407@arin.net>

Draft Policy 2010-13
Permitted Uses of space reserved under NRPM 4.10

Attached is the ARIN staff assessment of 2010-13. We assessed the 1.53
version of the draft policy (it's currently at 1.55). It is noted that
the time frame for reserves has been reduced from 36 to 24 months in
version 1.55.

This draft policy is open for discussion on this mailing list and will
be on the agenda at the upcoming ARIN Public Policy Meeting in Atlanta.

2010-13 is below and available at:
https://www.arin.net/policy/proposals/2010_13.html

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Staff Assessment of Draft Policy 2010-13 (version 1.53 dated 19
September 2010)

Permitted Uses of space reserved under NRPM 4.10

1. Proposal Summary (Staff Understanding)

This policy modifies the existing NRPM policy 4.10 (?Dedicated IPv4
block to facilitate IPv6 Deployment?).  It sets aside in its entirety
the last /8 ARIN receives from the IANA for issuance to networks
transitioning to a dual IPv4/IPv6 network rather than the /10 currently
cited in NRPM 4.10. Any IPv4 address space returned to ARIN (and not
subject to a global or regional transfer policy) will be added to this
transition pool.  Under this policy there are four major classes of
requestors:

   - ISPs can apply for /32s for customers as long as each customer
meets the policy's detailed qualification criteria.

   - Any operator can apply for /32s for issuing to devices used to
serve-up internet facing content, within the constraints of the defined
qualifying criteria.

   - From the /8, a /10 will be set aside so that any operator can
request space for use in infrastructure numbering for the purposes of
deploying IPv6. Space can be issued from this /8 for applicants who
qualify under ARIN's Micro-allocation Policy (with additional
restrictions).

   - Finally, space can be issued from this /8 for applicants who
operate content distribution networks, again, within the context of the
policy's qualifying criteria.

Organizations can request address space to meet their 3-year needs.
Space is allocated/assigned in quarterly installments.  After the first
quarter, the requestor can only return to ARIN if they have utilized 80%
of the most recent assignment, and 90% of past assignments (issued under
this policy). The organization must have also assigned all IP addresses
issued under the policy to uses that are acceptable under the policy.
If the organization fails to meet the utilization criteria for four
consecutive quarters, then the policy directs ARIN staff to reduce the
amount of space reserved.

2. Comments

  A.	ARIN Staff Comments

   ? The policy text has become very complex and complicated and the
general community will have a very hard time understanding the concepts
and criteria proposed within the policy.

   ? It seems to be out of order ? it starts out with reservations
before ever mentioning the initial qualifying criteria.  The author
might want to consider re-ordering to start with the essential
qualification criteria first.

   ? Section 4.10.2 suggests that all allocations made under this policy
will initially be made from a 3-year reservation.  In light of the
imminent depletion of IPv4 address space, it doesn't seem fair to allow
some organizations to retain/reserve this valuable resource for up to 3
years while others will be denied.

   ? The policy text in (in 4.10.3) appears to contradict itself, as it
first directs staff to remove one quarter's worth of reservation, and
then, if the organization continues this practice for three consecutive
quarters, remove the organization's reserves completely. Later, it
explicitly directs staff to revoke addresses issued under this policy
that are used by the organizations for purposes not permitted under this
policy.

   ? This proposal will essentially supplant the recently ratified
policy "Waiting List for Unmet Resources". That list will consist of
people waiting for resources to be returned or revoked so that ARIN can
then reissue them to requestors in need of IPv4 address space.  This
proposal says that any IPv4 address space that comes back to ARIN
immediately goes into the IPv6 transition pool and can only be used for
that purpose.

   ? Under 4.10.4.B5, how would staff be able to verify that x percent
of an organization?s content is IPv6 reachable?


  B. ARIN General Counsel
This policy is unlikely to cause any legal issues of any importance.


3. Resource Impact

This policy would have moderate to major resource impact.  It is
estimated that implementation would occur within 6 to 9 months after
ratification by the ARIN Board of Trustees. The following would be
needed in order to implement:
   ? Changes to the way ARIN manages reverse DNS (to handle in-addr.arpa
delegations for blocks smaller than /24)
   ? Updated guidelines
   ? Staff training


> -----Original Message-----

> From: Owen DeLong [mailto:owen at delong.com]

> Sent: Thursday, September 23, 2010 7:26 PM

> To: arin-ppml at arin.net List; policy

> Subject: Final draft of 2010-13 for Atlanta (Rev 1.55)

>

> Changes:

>

> 1. Set maximum reservation period to 24 months. This avoids creating

> a 4-year reservation by CIDR-rounding 36 month reservations.

> 2. Reduced minimum size for 4.10.4(b) to /28

>

> These changes will make the policy more balanced and reduce the extent

> to

> which larger organizations could be disadvantaged relative to smaller

> smaller organizations if reservations have to be resized.

>

> The change to a 2-year system resolves an issue with the CIDR-Rounding

> where a 36-month reservation is mathematically guaranteed to become a

> 48-month reservation. The other alternative was to round-down instead

> of

> up which would have mathematically converted all reservations to 2

> years.

> As such, a 2-year reservation system seemed the cleanest and most

> straightforward approach.

>

> Owen

>

> Draft Policy 2010-13: Permitted Uses of Space Reserved under NRPM 4.10

> Proposal Originator: Owen DeLong, Chris Grundemann

> Proposal Version: 1.55

> Date: 23 September 2010

> Proposal type: modify

> Policy term: permanent

> Policy statement:

>

> Remove section 4.1.8 (Unmet requests) from the NRPM.

> Replace the text of section 4.10 in its entirety (including the name)

> with:

>

> 4.10 IPv4 Transition Pool Post IANA Regular Pool Depletion

>

> When ARIN receives its /8 IPv4 allocation from IANA under the

> global policy titled "Global Policy for the Allocation of the

> Remaining IPv4 Address Space" ratified by ICANN Board

> on 6 March, 2009, that /8 will form a dedicated pool to

> facilitate IPv6 Deployment.

>

> Addresses returned to ARIN and not subject to a regional or

> global transfer policy will be reserved for utilization in the

> transition

> pool.

>

> Allocations and assignments from this block must be justified by

> IPv6 transition requirements.

>

> ARIN will use their discretion in determining whether a

> particular

> application meets the spirit of this policy.

>

> 4.10.1 Addressing Plan

>

> Any organization wishing to receive IPv4 addresses through this

> policy must submit a detailed addressing plan for any request

> that is made containing the following:

> (a) Their addressing needs over the entire reservation period

> and

> (b) Methods of meeting all requirements (requirements are

> explained in section 4.10.4.) over the entire reservation

> period.

>

> 4.10.2 Reservation System

>

> Initially, all space assigned or allocated under this policy will

> be

> reserved in advance for a maximum period of 24 months, requests

> for

> shorter reservations will be accepted. The total reservation size

> will be rounded up to a CIDR bit boundary.

>

> Each organization's reservation amount will be divided

> into quarterly allotments. Allotments will be rounded up

> to a CIDR bit boundary. The final quarterly allotment will

> contain only the remaining space from the full reservation.

>

> An organization may request one reservation under each provision

> listed in section 4.10.4. Once a reservation has been satisfied,

> another may be requested.

>

> 4.10.2.1 Reservation Requests Prior to Initial ARIN Free Pool

> Depletion

>

> Reservations will be accepted from the time that this policy

> is adopted until the day that ARIN can no longer fill regular

> requests from

> space allocated to ARIN by IANA. At that time, if necessary, all

> reservations

> will be reduced by an equal amount to allow them to fit within

> the total space available in the transition pool. No reservation

> will be reduced lower than the minimum quarterly allotment for

> it's category. Each organization may decide whether to adjust

> the reservation period or the allotment size (within the stated

> range) when reservations are reduced. Organizations must make

> this decision within 30 days of announcement and may not alter

> their choice once made. Any space added to the transition

> pool during this time will cause a final recalculation of

> reservation sizes. Once all necessary adjustments are

> made, all reservations are guaranteed and the first quarterly

> allotment is issued to each org.

>

> 4.10.2.2 Reservation Requests Post ARIN Free Pool Depletion

>

> Reservation requests received after ARIN free pool depletion

> as defined in 4.10.2.1 will not be guaranteed. If approved, such

> requests will be placed in a queue. As space becomes available in

> the transition pool it will be used to provide allotments to

> organizations with reservations in the queue on a first-approved

> first-served basis. Partially filled allotments will remain at

> the

> front of the queue.

>

> 4.10.2.3 Abandonment of Reservation

>

> Any organization may abandon their remaining reservation at any

> time by informing ARIN of their desire to do so. Upon

> abandonment,

> the remaining space in the reservation will be returned to the

> transition pool.

>

> 4.10.3 Quarterly Requirements

>

> Organizations with approved reservations and address plans

> are entitled to quarterly allotments. In order to receive each

> additional allotment, an organization must submit evidence of

> compliance with the following sub-sections:

> (a) The most recent 4.10 allotment is at least 80% utilized.

> (b) All prior 4.10 allotments within the same 4.10.4

> category are at least 90% utilized.

> (c) All utilization is permitted under the 4.10.4 category for

> which it was initially requested.

>

> For purposes of this computation, space received under each

> provision shall be considered separately if an organization has

> received resources through multiple provisions.

>

> If an organization does not meet all obligations in any given

> quarter, that organization shall not receive that quarter's

> allotment

> and shall have their reservation reduced by one quarterly

> allotment.

> If an organization does not meet all obligations

> for three consecutive quarters, that organization forfeits the

> remainder

> of their reserved block.

>

> Utilization requirements (a) may be delayed at ARIN's discretion.

>

> If an organization is using space received under 4.10 in a manner

> contrary to 4.10, that organization forfeits their remaining

> reservation and may have their entire allocation or assignment

> revoked.

>

> All 4.10. space forfeited, revoked or otherwise reclaimed shall

> be returned to the ARIN transition pool.

>

> 4.10.4 Specific types of transitional uses have specific

> requirements:

>

> (a) An ISP/LIR may request a block no smaller than a /25 nor

> larger than a /18 per quarter to be used to provide single

> IPv4 /32s to their customers which could justify a /28 or

> more of IPv4 under ARIN policies in effect at the time of

> IANA depletion.

> 1. No customer site may receive more than a single

> IPv4 /32 per 1,000 Internet connected hosts upto 8

> /32s.

> 2. The customer site must not have any IPv4

> addresses not issued under this policy.

> 3. The customer site must use the /32 to provide

> IPv4 connectivity for hosts which have IPv6

> addresses with IPv6 connectivity to the ISP/LIR.

> 4. The ISP/LIR must demonstrate that it already

> provides IPv6 addressing and connectivity to at

> least one additional existing customer site for

> each /32 requested, up to 90% of all customer sites

> served (across all customers).

> 5. An ISP/LIR customer which is not large enough to

> qualify

> under this provision and has no unassigned IPv4

> addresses

> may receive an appropriate number of /32s from their

> upstream provider for reassignment to their customers

> under the terms of 4.10.4(a).

> 6. A customer site which terminates multiple connections

> from the same provider on separate routers may

> qualify

> for one /32 per unique router with a direct

> connection to

> the provider, up to a total of 8 /32s.

> 7. The total space issued to all organizations under

> this provision shall not exceed an aggregate /9

> or equivalent per /8 placed into the transition pool.

>

>

> (b) An ISP/LIR or End user organization may request a block

> no smaller than a /28 and no larger than a /18 per quarter

> to provide single IPv4 /32s to each physical server used

> to provide Internet reachable content.

> 1. Space issued under this provision is an assignment,

> not an allocation. An LIR may not distribute this

> space to their customers.

> 2. No server may receive more than a single IPv4 /32

> under this provision.

> 3. The server must have IPv6 addresses with IPv6

> connectivity (must be dual-stacked).

> 4. The receiving organization must demonstrate that it

> already provides IPv6 addressing and connectivity

> to at least one additional existing server

> (organizations which can show 100% dual stack are

> exempt from this requirement).

> 5. The receiving organization must IPv6 enable all of

> their content on the following schedule:

>

> + 25% of content IPv6 reachable within six

> months of receiving their first addresses

> under this policy

> + 50% of content IPv6 reachable within one year

> of receiving their first addresses under this

> policy

> + 75% of content IPv6 reachable within 18 months

> of receiving their first addresses under this

> policy

> + 90% of content IPv6 reachable within 24 months

> of receiving their first addresses under this

> policy

> 6. A network providing SSL terminations for applications

> or content acceleration may receive a /32 for each

> distinguished name by following all requirements in

> this provision, substituting "distinguished name" for

> "server."

> 7. Networks using these addresses for authoritative

> DNS servers can use 2 /32s per 1,000 authoritative

> domains served up to 128 /32s total per organization.

> 8. The total space issued to all organizations under

> this provision shall not exceed an aggregate /9

> or equivalent per /8 placed into the transition pool.

>

> (c) An ISP/LIR or End user organization may request a block no

> smaller than a /29 and no larger than a /25 per quarter for

> purposes relevant to their ability to deploy IPv6.

> 1. Space issued under this provision is an assignment,

> not an allocation. An LIR may not distribute this

> space to their customers.

> 2. Space issued under this provision must be used to

> provide the required public IPv4 address(es) for

> transitional technologies operated by the recipient

> organization.

>

> Specific examples of permitted uses are:

> a. Large scale or "Carrier Grade" NAT

> b. NAT-PT

> c. DS-LITE/B4/AFTeR

> d. IVI

> e. DNS64 or other transitional DNS enablers

> f. Other technologies of similar purpose

> and scope.

>

> 3. A /10 from the final /8 shall be reserved for

> issuance

> under this provision. In no case shall any addresses

> from this /10 be issued for any purpose outside

> of 4.10.4(c).

>

> (d) Applications which would qualify for IPv4 under section 4.4

> of

> the NRPM (critical infrastructure) may qualify for IPv4

> space

> under this policy if they meet the following criteria:

> 1. The critical infrastructure to be numbered must also

> have IPv6 addresses and must provide all services

> provided on IPv4 over IPv6 on the same time table.

> 2. Assignments under this provision shall be the

> smallest technically feasible size for the critical

> infrastructure in question.

> 3. The total space assigned under this provision shall

> not

> exceed the equivalent of a /14.

>

> 
> >

>

>

> Rationale:

>

> The current terminology in section 4.10 is vague and could allow a

> variety of interpretations which could lead to allocations or

> assignments being made to ISPs intending to misuse the space for

> general deployment by using IPv6 overlay technologies as a "IPv6

> deployments" requiring IPv4 space for transition. For example, the

> current policy could be interpreted to enable an ISP to require IPv4

> addresses for all IPv6 customers to roll IPv6 out as 6rd to customers

> who would be otherwise unable to get IPv4 space. This is clearly

> outside of the original intent of the proposal which created 4.10 (6rd

> was not yet envisioned at the time that was written). This proposal

> seeks to clarify that intent and tighten up the requirements for

> organizations seeking to get space from this limited final resource so

> that it truly is available to facilitate transitional technologies.

>

> Additionally, there are a number of community segments that are not

> well served by the original intent of 4.10 and several community

> members requested a mechanism for providing a certain amount of

> certainty with regards to obtaining space at the end. While it would be

> impossible to guarantee organizations all the space they need as runout

> is upon us, this policy seeks to provide a way for organizations to

> sign up for and receive a reservation from the final space

> proportionate to their need. The policy also includes guidelines

> intended to ensure that this vital community resource is given only to

> organizations working towards a smooth transition to IPv6 to the

> benefit of the full community.

>

> In order to meet these needs, this policy has become very complex. It

> is an unfortunate artifact of the complex issue it seeks to address. A

> great deal of effort has been made to simplify the policy as much as

> possible, and, special thinks go out to several members of the

> community for their assistance in this matter.

>

> One provision in this draft policy calls for utilization criteria which

> may be waived by ARIN staff discretion. The intent of this clause is to

> allow staff to avoid penalizing an organization for successful address

> conservation efforts.

>

> Runout is upon us. IANA will run out of the IANA free pool and issue

> the last /8 this policy seeks to regulate before the next ARIN public

> policy meeting. If we are to make any attempt at fair distribution for

> the sake of IPv6 deployment, this is our final opportunity to do so

> outside of an emergency action by the ARIN board.

>

> Timetable for implementation: immediate

>

> For reference, here is the current text of 4.10

>

> 4.10 Dedicated IPv4 block to facilitate IPv6 Deployment

>

> When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous

> /10 IPv4 block will be set aside and dedicated to facilitate IPv6

> deployment. Allocations and assignments from this block must be

> justified by immediate IPv6 deployment requirements. Examples of such

> needs include: IPv4 addresses for key dual stack DNS servers, and NAT-

> PT or NAT464 translators. ARIN staff will use their discretion when

> evaluating justifications.

>

> This block will be subject to a minimum size allocation of /28 and a

> maximum size allocation of /24. ARIN should use sparse allocation when

> possible within that /10 block.

>

> In order to receive an allocation or assignment under this policy:

> 1. the applicant may not have received resources under this

> policy in the preceding six months;

> 2. previous allocations/assignments under this policy must

> continue to meet the justification requirements of this policy;

> 3. previous allocations/assignments under this policy must meet

> the utilization requirements of end user assignments;

> 4. the applicant must demonstrate that no other allocations or

> assignments will meet this need;

> 5. on subsequent allocation under this policy, ARIN staff may

> require applicants to renumber out of previously allocated / assigned

> space under this policy in order to minimize non-contiguous

> allocations.






From owen at delong.com  Tue Sep 28 00:05:50 2010
From: owen at delong.com (Owen DeLong)
Date: Mon, 27 Sep 2010 21:05:50 -0700
Subject: [arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55)
In-Reply-To: <4CA0F85A.20407@arin.net>
References: <4CA0F85A.20407@arin.net>
Message-ID: 

> 
> 2. Comments
> 
> A.	ARIN Staff Comments
> 
>  ? The policy text has become very complex and complicated and the
> general community will have a very hard time understanding the concepts
> and criteria proposed within the policy.
> 
It is an effort to bring a complex set of needs to a fair and workable solution.
As such, there were no simple solutions to be had. We have simplified it
tremendously from several earlier drafts.

>  ? It seems to be out of order ? it starts out with reservations
> before ever mentioning the initial qualifying criteria.  The author
> might want to consider re-ordering to start with the essential
> qualification criteria first.
> 
We felt that since understanding the reservation system was a
prerequisite to any application under the subsequent guidelines,
it should be explained first. I still think the policy is far easier to
understand if you start with understanding the reservation system
and then move to the criteria by which you can qualify for a
reservation.

>  ? Section 4.10.2 suggests that all allocations made under this policy
> will initially be made from a 3-year reservation.  In light of the
> imminent depletion of IPv4 address space, it doesn't seem fair to allow
> some organizations to retain/reserve this valuable resource for up to 3
> years while others will be denied.
> 
We shortened this to two years. Additionally, reservations will be
reduced as necessary to avoid denying space to anyone to the
extent feasible. The reservation system is required in order to provide
a limited amount of certainty to organizations trying to plan their
transitions between now and runout.

>  ? The policy text in (in 4.10.3) appears to contradict itself, as it
> first directs staff to remove one quarter's worth of reservation, and
> then, if the organization continues this practice for three consecutive
> quarters, remove the organization's reserves completely. Later, it
> explicitly directs staff to revoke addresses issued under this policy
> that are used by the organizations for purposes not permitted under this
> policy.
> 
These are two completely separate issues.

The first (quarterly reduction on first failure and cancellation of remaining
reserves on failure for three consecutive quarters) addresses the situation
where an organization is using the addresses in a manner consistent with
policy, but, either is not consuming their full reservation (over-reserved) or
is not meeting their IPv6 deployment targets. In these cases, we do not
seek to revoke the transition space from the organization, but, we do feel
it is only fair to return their reserved unallocated space to the pool for the
benefit of the community.

The second case addresses a situation where an organization uses
the addresses in a manner inconsistent with the policy under which
they were issued. This is essentially intended to prevent organizations
from taking addresses under this policy for uses other than transition
and provides the stiff penalty of not only canceling the remaining
reservation, but, also revoking any previously issued transition
space from the organization and returning it to the pool for the benefit
of the community.

>  ? This proposal will essentially supplant the recently ratified
> policy "Waiting List for Unmet Resources". That list will consist of
> people waiting for resources to be returned or revoked so that ARIN can
> then reissue them to requestors in need of IPv4 address space.  This
> proposal says that any IPv4 address space that comes back to ARIN
> immediately goes into the IPv6 transition pool and can only be used for
> that purpose.
> 
Yes... We feel that this is a better use of returned address space after
depletion.

>  ? Under 4.10.4.B5, how would staff be able to verify that x percent
> of an organization?s content is IPv6 reachable?
> 
In part, this will depend on some level of voluntary compliance. However,
I believe that the community would find ways to make ARIN aware of
egregious violations.

While we leave the exact method of measurement and implementation
as an operational issue for staff, since staff appears to be asking for
guidance, some possible techniques could include:

1.	Measure percentage by host distinguished names (DNs).
2.	Require the provider to submit a complete list of DNs.
3.	Count the number of DNs providing A vs. A/AAAA records.
4.	The simple ratio would represent the percentage.

Owen



From marty at akamai.com  Tue Sep 28 17:55:37 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Tue, 28 Sep 2010 17:55:37 -0400
Subject: [arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55)
In-Reply-To: <4CA0F85A.20407@arin.net>
Message-ID: 



I oppose this proposal. I think it's destructive; it's complicated and fails
to establish any leadership and it's divisive; the reservation system and
classes of requests create significant inequities for all that have need. It
fails to allow anyone to plan. The end result is that we're going to pit all
of our members against each other in open markets. Regardless of this
proposal, that may happen still. When I supported the petition I had hoped
that we could stretch this remaining space and provide some relief and
define what's important with regards to continuing to grow the net while we
transition. That is impossible with this proposal and perhaps impossible
with any proposal and a single /8[1]. [ The recent CableLabs Draft is very
interesting FWIW]

This proposal still does not go far enough in offering some level of relief
to all segments of the industry. I concur with the staff comments related
and specifically comments related to the complexity.

I did support "the concept" of the reservation system with different terms
and provider relief with respect to CPE et. Al. The proposal fails to
explain itself adequately with respect to both and if it were adequately
explained it may seem less unfair if it were re-written. Transition not be
without pain and some of us are already challenged by it.

I don't have a suggestion other than a complete rewrite which is why I
support completely abandoning it.


Best,

-M<



1. http://tools.ietf.org/html/draft-weil-opsawg-provider-address-space-00






On 9/27/10 4:02 PM, "ARIN"  wrote:

> Draft Policy 2010-13
> Permitted Uses of space reserved under NRPM 4.10
>
> Attached is the ARIN staff assessment of 2010-13. We assessed the 1.53
> version of the draft policy (it's currently at 1.55). It is noted that
> the time frame for reserves has been reduced from 36 to 24 months in
> version 1.55.
>
> This draft policy is open for discussion on this mailing list and will
> be on the agenda at the upcoming ARIN Public Policy Meeting in Atlanta.
>
> 2010-13 is below and available at:
> https://www.arin.net/policy/proposals/2010_13.html
>
> Regards,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Staff Assessment of Draft Policy 2010-13 (version 1.53 dated 19
> September 2010)
>
> Permitted Uses of space reserved under NRPM 4.10
>
> 1. Proposal Summary (Staff Understanding)
>
> This policy modifies the existing NRPM policy 4.10 (?Dedicated IPv4
> block to facilitate IPv6 Deployment?).  It sets aside in its entirety
> the last /8 ARIN receives from the IANA for issuance to networks
> transitioning to a dual IPv4/IPv6 network rather than the /10 currently
> cited in NRPM 4.10. Any IPv4 address space returned to ARIN (and not
> subject to a global or regional transfer policy) will be added to this
> transition pool.  Under this policy there are four major classes of
> requestors:
>
>    - ISPs can apply for /32s for customers as long as each customer
> meets the policy's detailed qualification criteria.
>
>    - Any operator can apply for /32s for issuing to devices used to
> serve-up internet facing content, within the constraints of the defined
> qualifying criteria.
>
>    - From the /8, a /10 will be set aside so that any operator can
> request space for use in infrastructure numbering for the purposes of
> deploying IPv6. Space can be issued from this /8 for applicants who
> qualify under ARIN's Micro-allocation Policy (with additional
> restrictions).
>
>    - Finally, space can be issued from this /8 for applicants who
> operate content distribution networks, again, within the context of the
> policy's qualifying criteria.
>
> Organizations can request address space to meet their 3-year needs.
> Space is allocated/assigned in quarterly installments.  After the first
> quarter, the requestor can only return to ARIN if they have utilized 80%
> of the most recent assignment, and 90% of past assignments (issued under
> this policy). The organization must have also assigned all IP addresses
> issued under the policy to uses that are acceptable under the policy.
> If the organization fails to meet the utilization criteria for four
> consecutive quarters, then the policy directs ARIN staff to reduce the
> amount of space reserved.
>
> 2. Comments
>
>   A.    ARIN Staff Comments
>
>    ? The policy text has become very complex and complicated and the
> general community will have a very hard time understanding the concepts
> and criteria proposed within the policy.
>
>    ? It seems to be out of order ? it starts out with reservations
> before ever mentioning the initial qualifying criteria.  The author
> might want to consider re-ordering to start with the essential
> qualification criteria first.
>
>    ? Section 4.10.2 suggests that all allocations made under this policy
> will initially be made from a 3-year reservation.  In light of the
> imminent depletion of IPv4 address space, it doesn't seem fair to allow
> some organizations to retain/reserve this valuable resource for up to 3
> years while others will be denied.
>
>    ? The policy text in (in 4.10.3) appears to contradict itself, as it
> first directs staff to remove one quarter's worth of reservation, and
> then, if the organization continues this practice for three consecutive
> quarters, remove the organization's reserves completely. Later, it
> explicitly directs staff to revoke addresses issued under this policy
> that are used by the organizations for purposes not permitted under this
> policy.
>
>    ? This proposal will essentially supplant the recently ratified
> policy "Waiting List for Unmet Resources". That list will consist of
> people waiting for resources to be returned or revoked so that ARIN can
> then reissue them to requestors in need of IPv4 address space.  This
> proposal says that any IPv4 address space that comes back to ARIN
> immediately goes into the IPv6 transition pool and can only be used for
> that purpose.
>
>    ? Under 4.10.4.B5, how would staff be able to verify that x percent
> of an organization?s content is IPv6 reachable?
>
>
>   B. ARIN General Counsel
> This policy is unlikely to cause any legal issues of any importance.
>
>
> 3. Resource Impact
>
> This policy would have moderate to major resource impact.  It is
> estimated that implementation would occur within 6 to 9 months after
> ratification by the ARIN Board of Trustees. The following would be
> needed in order to implement:
>    ? Changes to the way ARIN manages reverse DNS (to handle in-addr.arpa
> delegations for blocks smaller than /24)
>    ? Updated guidelines
>    ? Staff training
>
>
>> -----Original Message-----
>
>> From: Owen DeLong [mailto:owen at delong.com]
>
>> Sent: Thursday, September 23, 2010 7:26 PM
>
>> To: arin-ppml at arin.net List; policy
>
>> Subject: Final draft of 2010-13 for Atlanta (Rev 1.55)
>
>>
>
>> Changes:
>
>>
>
>> 1. Set maximum reservation period to 24 months. This avoids creating
>
>> a 4-year reservation by CIDR-rounding 36 month reservations.
>
>> 2. Reduced minimum size for 4.10.4(b) to /28
>
>>
>
>> These changes will make the policy more balanced and reduce the extent
>
>> to
>
>> which larger organizations could be disadvantaged relative to smaller
>
>> smaller organizations if reservations have to be resized.
>
>>
>
>> The change to a 2-year system resolves an issue with the CIDR-Rounding
>
>> where a 36-month reservation is mathematically guaranteed to become a
>
>> 48-month reservation. The other alternative was to round-down instead
>
>> of
>
>> up which would have mathematically converted all reservations to 2
>
>> years.
>
>> As such, a 2-year reservation system seemed the cleanest and most
>
>> straightforward approach.
>
>>
>
>> Owen
>
>>
>
>> Draft Policy 2010-13: Permitted Uses of Space Reserved under NRPM 4.10
>
>> Proposal Originator: Owen DeLong, Chris Grundemann
>
>> Proposal Version: 1.55
>
>> Date: 23 September 2010
>
>> Proposal type: modify
>
>> Policy term: permanent
>
>> Policy statement:
>
>>
>
>> Remove section 4.1.8 (Unmet requests) from the NRPM.
>
>> Replace the text of section 4.10 in its entirety (including the name)
>
>> with:
>
>>
>
>> 4.10 IPv4 Transition Pool Post IANA Regular Pool Depletion
>
>>
>
>> When ARIN receives its /8 IPv4 allocation from IANA under the
>
>> global policy titled "Global Policy for the Allocation of the
>
>> Remaining IPv4 Address Space" ratified by ICANN Board
>
>> on 6 March, 2009, that /8 will form a dedicated pool to
>
>> facilitate IPv6 Deployment.
>
>>
>
>> Addresses returned to ARIN and not subject to a regional or
>
>> global transfer policy will be reserved for utilization in the
>
>> transition
>
>> pool.
>
>>
>
>> Allocations and assignments from this block must be justified by
>
>> IPv6 transition requirements.
>
>>
>
>> ARIN will use their discretion in determining whether a
>
>> particular
>
>> application meets the spirit of this policy.
>
>>
>
>> 4.10.1 Addressing Plan
>
>>
>
>> Any organization wishing to receive IPv4 addresses through this
>
>> policy must submit a detailed addressing plan for any request
>
>> that is made containing the following:
>
>> (a) Their addressing needs over the entire reservation period
>
>> and
>
>> (b) Methods of meeting all requirements (requirements are
>
>> explained in section 4.10.4.) over the entire reservation
>
>> period.
>
>>
>
>> 4.10.2 Reservation System
>
>>
>
>> Initially, all space assigned or allocated under this policy will
>
>> be
>
>> reserved in advance for a maximum period of 24 months, requests
>
>> for
>
>> shorter reservations will be accepted. The total reservation size
>
>> will be rounded up to a CIDR bit boundary.
>
>>
>
>> Each organization's reservation amount will be divided
>
>> into quarterly allotments. Allotments will be rounded up
>
>> to a CIDR bit boundary. The final quarterly allotment will
>
>> contain only the remaining space from the full reservation.
>
>>
>
>> An organization may request one reservation under each provision
>
>> listed in section 4.10.4. Once a reservation has been satisfied,
>
>> another may be requested.
>
>>
>
>> 4.10.2.1 Reservation Requests Prior to Initial ARIN Free Pool
>
>> Depletion
>
>>
>
>> Reservations will be accepted from the time that this policy
>
>> is adopted until the day that ARIN can no longer fill regular
>
>> requests from
>
>> space allocated to ARIN by IANA. At that time, if necessary, all
>
>> reservations
>
>> will be reduced by an equal amount to allow them to fit within
>
>> the total space available in the transition pool. No reservation
>
>> will be reduced lower than the minimum quarterly allotment for
>
>> it's category. Each organization may decide whether to adjust
>
>> the reservation period or the allotment size (within the stated
>
>> range) when reservations are reduced. Organizations must make
>
>> this decision within 30 days of announcement and may not alter
>
>> their choice once made. Any space added to the transition
>
>> pool during this time will cause a final recalculation of
>
>> reservation sizes. Once all necessary adjustments are
>
>> made, all reservations are guaranteed and the first quarterly
>
>> allotment is issued to each org.
>
>>
>
>> 4.10.2.2 Reservation Requests Post ARIN Free Pool Depletion
>
>>
>
>> Reservation requests received after ARIN free pool depletion
>
>> as defined in 4.10.2.1 will not be guaranteed. If approved, such
>
>> requests will be placed in a queue. As space becomes available in
>
>> the transition pool it will be used to provide allotments to
>
>> organizations with reservations in the queue on a first-approved
>
>> first-served basis. Partially filled allotments will remain at
>
>> the
>
>> front of the queue.
>
>>
>
>> 4.10.2.3 Abandonment of Reservation
>
>>
>
>> Any organization may abandon their remaining reservation at any
>
>> time by informing ARIN of their desire to do so. Upon
>
>> abandonment,
>
>> the remaining space in the reservation will be returned to the
>
>> transition pool.
>
>>
>
>> 4.10.3 Quarterly Requirements
>
>>
>
>> Organizations with approved reservations and address plans
>
>> are entitled to quarterly allotments. In order to receive each
>
>> additional allotment, an organization must submit evidence of
>
>> compliance with the following sub-sections:
>
>> (a) The most recent 4.10 allotment is at least 80% utilized.
>
>> (b) All prior 4.10 allotments within the same 4.10.4
>
>> category are at least 90% utilized.
>
>> (c) All utilization is permitted under the 4.10.4 category for
>
>> which it was initially requested.
>
>>
>
>> For purposes of this computation, space received under each
>
>> provision shall be considered separately if an organization has
>
>> received resources through multiple provisions.
>
>>
>
>> If an organization does not meet all obligations in any given
>
>> quarter, that organization shall not receive that quarter's
>
>> allotment
>
>> and shall have their reservation reduced by one quarterly
>
>> allotment.
>
>> If an organization does not meet all obligations
>
>> for three consecutive quarters, that organization forfeits the
>
>> remainder
>
>> of their reserved block.
>
>>
>
>> Utilization requirements (a) may be delayed at ARIN's discretion.
>
>>
>
>> If an organization is using space received under 4.10 in a manner
>
>> contrary to 4.10, that organization forfeits their remaining
>
>> reservation and may have their entire allocation or assignment
>
>> revoked.
>
>>
>
>> All 4.10. space forfeited, revoked or otherwise reclaimed shall
>
>> be returned to the ARIN transition pool.
>
>>
>
>> 4.10.4 Specific types of transitional uses have specific
>
>> requirements:
>
>>
>
>> (a) An ISP/LIR may request a block no smaller than a /25 nor
>
>> larger than a /18 per quarter to be used to provide single
>
>> IPv4 /32s to their customers which could justify a /28 or
>
>> more of IPv4 under ARIN policies in effect at the time of
>
>> IANA depletion.
>
>> 1. No customer site may receive more than a single
>
>> IPv4 /32 per 1,000 Internet connected hosts upto 8
>
>> /32s.
>
>> 2. The customer site must not have any IPv4
>
>> addresses not issued under this policy.
>
>> 3. The customer site must use the /32 to provide
>
>> IPv4 connectivity for hosts which have IPv6
>
>> addresses with IPv6 connectivity to the ISP/LIR.
>
>> 4. The ISP/LIR must demonstrate that it already
>
>> provides IPv6 addressing and connectivity to at
>
>> least one additional existing customer site for
>
>> each /32 requested, up to 90% of all customer sites
>
>> served (across all customers).
>
>> 5. An ISP/LIR customer which is not large enough to
>
>> qualify
>
>> under this provision and has no unassigned IPv4
>
>> addresses
>
>> may receive an appropriate number of /32s from their
>
>> upstream provider for reassignment to their customers
>
>> under the terms of 4.10.4(a).
>
>> 6. A customer site which terminates multiple connections
>
>> from the same provider on separate routers may
>
>> qualify
>
>> for one /32 per unique router with a direct
>
>> connection to
>
>> the provider, up to a total of 8 /32s.
>
>> 7. The total space issued to all organizations under
>
>> this provision shall not exceed an aggregate /9
>
>> or equivalent per /8 placed into the transition pool.
>
>>
>
>>
>
>> (b) An ISP/LIR or End user organization may request a block
>
>> no smaller than a /28 and no larger than a /18 per quarter
>
>> to provide single IPv4 /32s to each physical server used
>
>> to provide Internet reachable content.
>
>> 1. Space issued under this provision is an assignment,
>
>> not an allocation. An LIR may not distribute this
>
>> space to their customers.
>
>> 2. No server may receive more than a single IPv4 /32
>
>> under this provision.
>
>> 3. The server must have IPv6 addresses with IPv6
>
>> connectivity (must be dual-stacked).
>
>> 4. The receiving organization must demonstrate that it
>
>> already provides IPv6 addressing and connectivity
>
>> to at least one additional existing server
>
>> (organizations which can show 100% dual stack are
>
>> exempt from this requirement).
>
>> 5. The receiving organization must IPv6 enable all of
>
>> their content on the following schedule:
>
>>
>
>> + 25% of content IPv6 reachable within six
>
>> months of receiving their first addresses
>
>> under this policy
>
>> + 50% of content IPv6 reachable within one year
>
>> of receiving their first addresses under this
>
>> policy
>
>> + 75% of content IPv6 reachable within 18 months
>
>> of receiving their first addresses under this
>
>> policy
>
>> + 90% of content IPv6 reachable within 24 months
>
>> of receiving their first addresses under this
>
>> policy
>
>> 6. A network providing SSL terminations for applications
>
>> or content acceleration may receive a /32 for each
>
>> distinguished name by following all requirements in
>
>> this provision, substituting "distinguished name" for
>
>> "server."
>
>> 7. Networks using these addresses for authoritative
>
>> DNS servers can use 2 /32s per 1,000 authoritative
>
>> domains served up to 128 /32s total per organization.
>
>> 8. The total space issued to all organizations under
>
>> this provision shall not exceed an aggregate /9
>
>> or equivalent per /8 placed into the transition pool.
>
>>
>
>> (c) An ISP/LIR or End user organization may request a block no
>
>> smaller than a /29 and no larger than a /25 per quarter for
>
>> purposes relevant to their ability to deploy IPv6.
>
>> 1. Space issued under this provision is an assignment,
>
>> not an allocation. An LIR may not distribute this
>
>> space to their customers.
>
>> 2. Space issued under this provision must be used to
>
>> provide the required public IPv4 address(es) for
>
>> transitional technologies operated by the recipient
>
>> organization.
>
>>
>
>> Specific examples of permitted uses are:
>
>> a. Large scale or "Carrier Grade" NAT
>
>> b. NAT-PT
>
>> c. DS-LITE/B4/AFTeR
>
>> d. IVI
>
>> e. DNS64 or other transitional DNS enablers
>
>> f. Other technologies of similar purpose
>
>> and scope.
>
>>
>
>> 3. A /10 from the final /8 shall be reserved for
>
>> issuance
>
>> under this provision. In no case shall any addresses
>
>> from this /10 be issued for any purpose outside
>
>> of 4.10.4(c).
>
>>
>
>> (d) Applications which would qualify for IPv4 under section 4.4
>
>> of
>
>> the NRPM (critical infrastructure) may qualify for IPv4
>
>> space
>
>> under this policy if they meet the following criteria:
>
>> 1. The critical infrastructure to be numbered must also
>
>> have IPv6 addresses and must provide all services
>
>> provided on IPv4 over IPv6 on the same time table.
>
>> 2. Assignments under this provision shall be the
>
>> smallest technically feasible size for the critical
>
>> infrastructure in question.
>
>> 3. The total space assigned under this provision shall
>
>> not
>
>> exceed the equivalent of a /14.
>
>>
>
>> 
> >> > >>
>
>>
>
>>
>
>> Rationale:
>
>>
>
>> The current terminology in section 4.10 is vague and could allow a
>
>> variety of interpretations which could lead to allocations or
>
>> assignments being made to ISPs intending to misuse the space for
>
>> general deployment by using IPv6 overlay technologies as a "IPv6
>
>> deployments" requiring IPv4 space for transition. For example, the
>
>> current policy could be interpreted to enable an ISP to require IPv4
>
>> addresses for all IPv6 customers to roll IPv6 out as 6rd to customers
>
>> who would be otherwise unable to get IPv4 space. This is clearly
>
>> outside of the original intent of the proposal which created 4.10 (6rd
>
>> was not yet envisioned at the time that was written). This proposal
>
>> seeks to clarify that intent and tighten up the requirements for
>
>> organizations seeking to get space from this limited final resource so
>
>> that it truly is available to facilitate transitional technologies.
>
>>
>
>> Additionally, there are a number of community segments that are not
>
>> well served by the original intent of 4.10 and several community
>
>> members requested a mechanism for providing a certain amount of
>
>> certainty with regards to obtaining space at the end. While it would be
>
>> impossible to guarantee organizations all the space they need as runout
>
>> is upon us, this policy seeks to provide a way for organizations to
>
>> sign up for and receive a reservation from the final space
>
>> proportionate to their need. The policy also includes guidelines
>
>> intended to ensure that this vital community resource is given only to
>
>> organizations working towards a smooth transition to IPv6 to the
>
>> benefit of the full community.
>
>>
>
>> In order to meet these needs, this policy has become very complex. It
>
>> is an unfortunate artifact of the complex issue it seeks to address. A
>
>> great deal of effort has been made to simplify the policy as much as
>
>> possible, and, special thinks go out to several members of the
>
>> community for their assistance in this matter.
>
>>
>
>> One provision in this draft policy calls for utilization criteria which
>
>> may be waived by ARIN staff discretion. The intent of this clause is to
>
>> allow staff to avoid penalizing an organization for successful address
>
>> conservation efforts.
>
>>
>
>> Runout is upon us. IANA will run out of the IANA free pool and issue
>
>> the last /8 this policy seeks to regulate before the next ARIN public
>
>> policy meeting. If we are to make any attempt at fair distribution for
>
>> the sake of IPv6 deployment, this is our final opportunity to do so
>
>> outside of an emergency action by the ARIN board.
>
>>
>
>> Timetable for implementation: immediate
>
>>
>
>> For reference, here is the current text of 4.10
>
>>
>
>> 4.10 Dedicated IPv4 block to facilitate IPv6 Deployment
>
>>
>
>> When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous
>
>> /10 IPv4 block will be set aside and dedicated to facilitate IPv6
>
>> deployment. Allocations and assignments from this block must be
>
>> justified by immediate IPv6 deployment requirements. Examples of such
>
>> needs include: IPv4 addresses for key dual stack DNS servers, and NAT-
>
>> PT or NAT464 translators. ARIN staff will use their discretion when
>
>> evaluating justifications.
>
>>
>
>> This block will be subject to a minimum size allocation of /28 and a
>
>> maximum size allocation of /24. ARIN should use sparse allocation when
>
>> possible within that /10 block.
>
>>
>
>> In order to receive an allocation or assignment under this policy:
>
>> 1. the applicant may not have received resources under this
>
>> policy in the preceding six months;
>
>> 2. previous allocations/assignments under this policy must
>
>> continue to meet the justification requirements of this policy;
>
>> 3. previous allocations/assignments under this policy must meet
>
>> the utilization requirements of end user assignments;
>
>> 4. the applicant must demonstrate that no other allocations or
>
>> assignments will meet this need;
>
>> 5. on subsequent allocation under this policy, ARIN staff may
>
>> require applicants to renumber out of previously allocated / assigned
>
>> space under this policy in order to minimize non-contiguous
>
>> allocations.
>
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From cgrundemann at gmail.com  Wed Sep 29 10:32:59 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Wed, 29 Sep 2010 08:32:59 -0600
Subject: [arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55)
In-Reply-To: 
References: <4CA0F85A.20407@arin.net>
	
Message-ID: 

I think the fact that ARIN Staff is concerned that this policy may
favor organizations who are granted reservations too much and Marty
believes that it does not go far enough to provide relief to those
same organizations illustrates that we have actually found a pretty
decent compromise.

On Tue, Sep 28, 2010 at 15:55, Hannigan, Martin  wrote:
>
> This proposal still does not go far enough in offering some level of relief
> to all segments of the industry.

The simple fact is that we are running out of IPv4 space. Absolutely
no policy can change that. Advancing transition to IPv6 across the
board is the best way (perhaps the only way) to ease all of our
growing pains going forward.

> On 9/27/10 4:02 PM, "ARIN"  wrote:
>>
>> ? A. ? ?ARIN Staff Comments
>>
>> ? ?? Section 4.10.2 suggests that all allocations made under this policy
>> will initially be made from a 3-year reservation. ?In light of the
>> imminent depletion of IPv4 address space, it doesn't seem fair to allow
>> some organizations to retain/reserve this valuable resource for up to 3
>> years while others will be denied.

I would like to point out that although the initial reservations are
for [now two years], there is a built in "fairness valve" as well.
Please see section 4.10.2.1 in the draft policy, which starts thus:

	Reservations will be accepted from the time that this policy
	is adopted until the day that ARIN can no longer fill regular requests from
	space allocated to ARIN by IANA. At that time, if necessary, all reservations
	will be reduced by an equal amount to allow them to fit within
	the total space available in the transition pool.

So everyone who is granted a reservation before run-out gets *some*
reservation, although it is not likely that anyone will get the full
reservation requested. I think this is the best balance of
predictability and inclusiveness possible.

Also note the second phase, post-exhaustion, detailed in section
4.10.2.2 which reads:

	Reservation requests received after ARIN free pool depletion
	as defined in 4.10.2.1 will not be guaranteed. If approved, such
	requests will be placed in a queue. As space becomes available in
	the transition pool it will be used to provide allotments to
	organizations with reservations in the queue on a first-approved
	first-served basis. Partially filled allotments will remain at the
	front of the queue.

So, *everyone* gets a shot at the transition space, and it comes down
to how much space ends up being available.

Overall, I think we have come up with the best possible (most fair)
soft-landing policy under the current constraints (constraints which
will only get tighter).

~Chris

>>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>

-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org


From rudi.daniel at gmail.com  Wed Sep 29 10:49:38 2010
From: rudi.daniel at gmail.com (Rudolph Daniel)
Date: Wed, 29 Sep 2010 10:49:38 -0400
Subject: [arin-ppml] ARIN-PPML Digest, Vol 63, Issue 32
In-Reply-To: 
References: 
Message-ID: 

I cannot support 2010-13 presently because it still seems to me to be
overtly complex prone to misunderstanding.

One example: >ISPs can apply for /32s for customers as long as each customer
> meets the policy's detailed qualification criteria. As an ISP, I may not
be too happy imposing detailed qualification criteria which will be a beyond
my commercial requirement and may simply frustrate and complicate the
process at all levels.

Rudi Daniel



On Wed, Sep 29, 2010 at 10:33 AM,  wrote:

> Send ARIN-PPML mailing list submissions to
>        arin-ppml at arin.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://lists.arin.net/mailman/listinfo/arin-ppml
> or, via email, send a message with subject or body 'help' to
>        arin-ppml-request at arin.net
>
> You can reach the person managing the list at
>        arin-ppml-owner at arin.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ARIN-PPML digest..."
>
>
> Today's Topics:
>
>   1. Re: Final draft of 2010-13 for Atlanta (Rev 1.55)
>      (Hannigan, Martin)
>   2. Re: Final draft of 2010-13 for Atlanta (Rev 1.55)
>      (Chris Grundemann)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 28 Sep 2010 17:55:37 -0400
> From: "Hannigan, Martin" 
> To: "arin-ppml at arin.net" 
> Subject: Re: [arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55)
> Message-ID: 
> >
> Content-Type: text/plain; charset="Windows-1252"
>
>
>
> I oppose this proposal. I think it's destructive; it's complicated and
> fails
> to establish any leadership and it's divisive; the reservation system and
> classes of requests create significant inequities for all that have need.
> It
> fails to allow anyone to plan. The end result is that we're going to pit
> all
> of our members against each other in open markets. Regardless of this
> proposal, that may happen still. When I supported the petition I had hoped
> that we could stretch this remaining space and provide some relief and
> define what's important with regards to continuing to grow the net while we
> transition. That is impossible with this proposal and perhaps impossible
> with any proposal and a single /8[1]. [ The recent CableLabs Draft is very
> interesting FWIW]
>
> This proposal still does not go far enough in offering some level of relief
> to all segments of the industry. I concur with the staff comments related
> and specifically comments related to the complexity.
>
> I did support "the concept" of the reservation system with different terms
> and provider relief with respect to CPE et. Al. The proposal fails to
> explain itself adequately with respect to both and if it were adequately
> explained it may seem less unfair if it were re-written. Transition not be
> without pain and some of us are already challenged by it.
>
> I don't have a suggestion other than a complete rewrite which is why I
> support completely abandoning it.
>
>
> Best,
>
> -M<
>
>
>
> 1. http://tools.ietf.org/html/draft-weil-opsawg-provider-address-space-00
>
>
>
>
>
>
> On 9/27/10 4:02 PM, "ARIN"  wrote:
>
> > Draft Policy 2010-13
> > Permitted Uses of space reserved under NRPM 4.10
> >
> > Attached is the ARIN staff assessment of 2010-13. We assessed the 1.53
> > version of the draft policy (it's currently at 1.55). It is noted that
> > the time frame for reserves has been reduced from 36 to 24 months in
> > version 1.55.
> >
> > This draft policy is open for discussion on this mailing list and will
> > be on the agenda at the upcoming ARIN Public Policy Meeting in Atlanta.
> >
> > 2010-13 is below and available at:
> > https://www.arin.net/policy/proposals/2010_13.html
> >
> > Regards,
> >
> > Communications and Member Services
> > American Registry for Internet Numbers (ARIN)
> >
> >
> > ## * ##
> >
> >
> > Staff Assessment of Draft Policy 2010-13 (version 1.53 dated 19
> > September 2010)
> >
> > Permitted Uses of space reserved under NRPM 4.10
> >
> > 1. Proposal Summary (Staff Understanding)
> >
> > This policy modifies the existing NRPM policy 4.10 (?Dedicated IPv4
> > block to facilitate IPv6 Deployment?).  It sets aside in its entirety
> > the last /8 ARIN receives from the IANA for issuance to networks
> > transitioning to a dual IPv4/IPv6 network rather than the /10 currently
> > cited in NRPM 4.10. Any IPv4 address space returned to ARIN (and not
> > subject to a global or regional transfer policy) will be added to this
> > transition pool.  Under this policy there are four major classes of
> > requestors:
> >
> >    - ISPs can apply for /32s for customers as long as each customer
> > meets the policy's detailed qualification criteria.
> >
> >    - Any operator can apply for /32s for issuing to devices used to
> > serve-up internet facing content, within the constraints of the defined
> > qualifying criteria.
> >
> >    - From the /8, a /10 will be set aside so that any operator can
> > request space for use in infrastructure numbering for the purposes of
> > deploying IPv6. Space can be issued from this /8 for applicants who
> > qualify under ARIN's Micro-allocation Policy (with additional
> > restrictions).
> >
> >    - Finally, space can be issued from this /8 for applicants who
> > operate content distribution networks, again, within the context of the
> > policy's qualifying criteria.
> >
> > Organizations can request address space to meet their 3-year needs.
> > Space is allocated/assigned in quarterly installments.  After the first
> > quarter, the requestor can only return to ARIN if they have utilized 80%
> > of the most recent assignment, and 90% of past assignments (issued under
> > this policy). The organization must have also assigned all IP addresses
> > issued under the policy to uses that are acceptable under the policy.
> > If the organization fails to meet the utilization criteria for four
> > consecutive quarters, then the policy directs ARIN staff to reduce the
> > amount of space reserved.
> >
> > 2. Comments
> >
> >   A.    ARIN Staff Comments
> >
> >    ? The policy text has become very complex and complicated and the
> > general community will have a very hard time understanding the concepts
> > and criteria proposed within the policy.
> >
> >    ? It seems to be out of order ? it starts out with reservations
> > before ever mentioning the initial qualifying criteria.  The author
> > might want to consider re-ordering to start with the essential
> > qualification criteria first.
> >
> >    ? Section 4.10.2 suggests that all allocations made under this policy
> > will initially be made from a 3-year reservation.  In light of the
> > imminent depletion of IPv4 address space, it doesn't seem fair to allow
> > some organizations to retain/reserve this valuable resource for up to 3
> > years while others will be denied.
> >
> >    ? The policy text in (in 4.10.3) appears to contradict itself, as it
> > first directs staff to remove one quarter's worth of reservation, and
> > then, if the organization continues this practice for three consecutive
> > quarters, remove the organization's reserves completely. Later, it
> > explicitly directs staff to revoke addresses issued under this policy
> > that are used by the organizations for purposes not permitted under this
> > policy.
> >
> >    ? This proposal will essentially supplant the recently ratified
> > policy "Waiting List for Unmet Resources". That list will consist of
> > people waiting for resources to be returned or revoked so that ARIN can
> > then reissue them to requestors in need of IPv4 address space.  This
> > proposal says that any IPv4 address space that comes back to ARIN
> > immediately goes into the IPv6 transition pool and can only be used for
> > that purpose.
> >
> >    ? Under 4.10.4.B5, how would staff be able to verify that x percent
> > of an organization?s content is IPv6 reachable?
> >
> >
> >   B. ARIN General Counsel
> > This policy is unlikely to cause any legal issues of any importance.
> >
> >
> > 3. Resource Impact
> >
> > This policy would have moderate to major resource impact.  It is
> > estimated that implementation would occur within 6 to 9 months after
> > ratification by the ARIN Board of Trustees. The following would be
> > needed in order to implement:
> >    ? Changes to the way ARIN manages reverse DNS (to handle in-addr.arpa
> > delegations for blocks smaller than /24)
> >    ? Updated guidelines
> >    ? Staff training
> >
> >
> >> -----Original Message-----
> >
> >> From: Owen DeLong [mailto:owen at delong.com]
> >
> >> Sent: Thursday, September 23, 2010 7:26 PM
> >
> >> To: arin-ppml at arin.net List; policy
> >
> >> Subject: Final draft of 2010-13 for Atlanta (Rev 1.55)
> >
> >>
> >
> >> Changes:
> >
> >>
> >
> >> 1. Set maximum reservation period to 24 months. This avoids creating
> >
> >> a 4-year reservation by CIDR-rounding 36 month reservations.
> >
> >> 2. Reduced minimum size for 4.10.4(b) to /28
> >
> >>
> >
> >> These changes will make the policy more balanced and reduce the extent
> >
> >> to
> >
> >> which larger organizations could be disadvantaged relative to smaller
> >
> >> smaller organizations if reservations have to be resized.
> >
> >>
> >
> >> The change to a 2-year system resolves an issue with the CIDR-Rounding
> >
> >> where a 36-month reservation is mathematically guaranteed to become a
> >
> >> 48-month reservation. The other alternative was to round-down instead
> >
> >> of
> >
> >> up which would have mathematically converted all reservations to 2
> >
> >> years.
> >
> >> As such, a 2-year reservation system seemed the cleanest and most
> >
> >> straightforward approach.
> >
> >>
> >
> >> Owen
> >
> >>
> >
> >> Draft Policy 2010-13: Permitted Uses of Space Reserved under NRPM 4.10
> >
> >> Proposal Originator: Owen DeLong, Chris Grundemann
> >
> >> Proposal Version: 1.55
> >
> >> Date: 23 September 2010
> >
> >> Proposal type: modify
> >
> >> Policy term: permanent
> >
> >> Policy statement:
> >
> >>
> >
> >> Remove section 4.1.8 (Unmet requests) from the NRPM.
> >
> >> Replace the text of section 4.10 in its entirety (including the name)
> >
> >> with:
> >
> >>
> >
> >> 4.10 IPv4 Transition Pool Post IANA Regular Pool Depletion
> >
> >>
> >
> >> When ARIN receives its /8 IPv4 allocation from IANA under the
> >
> >> global policy titled "Global Policy for the Allocation of the
> >
> >> Remaining IPv4 Address Space" ratified by ICANN Board
> >
> >> on 6 March, 2009, that /8 will form a dedicated pool to
> >
> >> facilitate IPv6 Deployment.
> >
> >>
> >
> >> Addresses returned to ARIN and not subject to a regional or
> >
> >> global transfer policy will be reserved for utilization in the
> >
> >> transition
> >
> >> pool.
> >
> >>
> >
> >> Allocations and assignments from this block must be justified by
> >
> >> IPv6 transition requirements.
> >
> >>
> >
> >> ARIN will use their discretion in determining whether a
> >
> >> particular
> >
> >> application meets the spirit of this policy.
> >
> >>
> >
> >> 4.10.1 Addressing Plan
> >
> >>
> >
> >> Any organization wishing to receive IPv4 addresses through this
> >
> >> policy must submit a detailed addressing plan for any request
> >
> >> that is made containing the following:
> >
> >> (a) Their addressing needs over the entire reservation period
> >
> >> and
> >
> >> (b) Methods of meeting all requirements (requirements are
> >
> >> explained in section 4.10.4.) over the entire reservation
> >
> >> period.
> >
> >>
> >
> >> 4.10.2 Reservation System
> >
> >>
> >
> >> Initially, all space assigned or allocated under this policy will
> >
> >> be
> >
> >> reserved in advance for a maximum period of 24 months, requests
> >
> >> for
> >
> >> shorter reservations will be accepted. The total reservation size
> >
> >> will be rounded up to a CIDR bit boundary.
> >
> >>
> >
> >> Each organization's reservation amount will be divided
> >
> >> into quarterly allotments. Allotments will be rounded up
> >
> >> to a CIDR bit boundary. The final quarterly allotment will
> >
> >> contain only the remaining space from the full reservation.
> >
> >>
> >
> >> An organization may request one reservation under each provision
> >
> >> listed in section 4.10.4. Once a reservation has been satisfied,
> >
> >> another may be requested.
> >
> >>
> >
> >> 4.10.2.1 Reservation Requests Prior to Initial ARIN Free Pool
> >
> >> Depletion
> >
> >>
> >
> >> Reservations will be accepted from the time that this policy
> >
> >> is adopted until the day that ARIN can no longer fill regular
> >
> >> requests from
> >
> >> space allocated to ARIN by IANA. At that time, if necessary, all
> >
> >> reservations
> >
> >> will be reduced by an equal amount to allow them to fit within
> >
> >> the total space available in the transition pool. No reservation
> >
> >> will be reduced lower than the minimum quarterly allotment for
> >
> >> it's category. Each organization may decide whether to adjust
> >
> >> the reservation period or the allotment size (within the stated
> >
> >> range) when reservations are reduced. Organizations must make
> >
> >> this decision within 30 days of announcement and may not alter
> >
> >> their choice once made. Any space added to the transition
> >
> >> pool during this time will cause a final recalculation of
> >
> >> reservation sizes. Once all necessary adjustments are
> >
> >> made, all reservations are guaranteed and the first quarterly
> >
> >> allotment is issued to each org.
> >
> >>
> >
> >> 4.10.2.2 Reservation Requests Post ARIN Free Pool Depletion
> >
> >>
> >
> >> Reservation requests received after ARIN free pool depletion
> >
> >> as defined in 4.10.2.1 will not be guaranteed. If approved, such
> >
> >> requests will be placed in a queue. As space becomes available in
> >
> >> the transition pool it will be used to provide allotments to
> >
> >> organizations with reservations in the queue on a first-approved
> >
> >> first-served basis. Partially filled allotments will remain at
> >
> >> the
> >
> >> front of the queue.
> >
> >>
> >
> >> 4.10.2.3 Abandonment of Reservation
> >
> >>
> >
> >> Any organization may abandon their remaining reservation at any
> >
> >> time by informing ARIN of their desire to do so. Upon
> >
> >> abandonment,
> >
> >> the remaining space in the reservation will be returned to the
> >
> >> transition pool.
> >
> >>
> >
> >> 4.10.3 Quarterly Requirements
> >
> >>
> >
> >> Organizations with approved reservations and address plans
> >
> >> are entitled to quarterly allotments. In order to receive each
> >
> >> additional allotment, an organization must submit evidence of
> >
> >> compliance with the following sub-sections:
> >
> >> (a) The most recent 4.10 allotment is at least 80% utilized.
> >
> >> (b) All prior 4.10 allotments within the same 4.10.4
> >
> >> category are at least 90% utilized.
> >
> >> (c) All utilization is permitted under the 4.10.4 category for
> >
> >> which it was initially requested.
> >
> >>
> >
> >> For purposes of this computation, space received under each
> >
> >> provision shall be considered separately if an organization has
> >
> >> received resources through multiple provisions.
> >
> >>
> >
> >> If an organization does not meet all obligations in any given
> >
> >> quarter, that organization shall not receive that quarter's
> >
> >> allotment
> >
> >> and shall have their reservation reduced by one quarterly
> >
> >> allotment.
> >
> >> If an organization does not meet all obligations
> >
> >> for three consecutive quarters, that organization forfeits the
> >
> >> remainder
> >
> >> of their reserved block.
> >
> >>
> >
> >> Utilization requirements (a) may be delayed at ARIN's discretion.
> >
> >>
> >
> >> If an organization is using space received under 4.10 in a manner
> >
> >> contrary to 4.10, that organization forfeits their remaining
> >
> >> reservation and may have their entire allocation or assignment
> >
> >> revoked.
> >
> >>
> >
> >> All 4.10. space forfeited, revoked or otherwise reclaimed shall
> >
> >> be returned to the ARIN transition pool.
> >
> >>
> >
> >> 4.10.4 Specific types of transitional uses have specific
> >
> >> requirements:
> >
> >>
> >
> >> (a) An ISP/LIR may request a block no smaller than a /25 nor
> >
> >> larger than a /18 per quarter to be used to provide single
> >
> >> IPv4 /32s to their customers which could justify a /28 or
> >
> >> more of IPv4 under ARIN policies in effect at the time of
> >
> >> IANA depletion.
> >
> >> 1. No customer site may receive more than a single
> >
> >> IPv4 /32 per 1,000 Internet connected hosts upto 8
> >
> >> /32s.
> >
> >> 2. The customer site must not have any IPv4
> >
> >> addresses not issued under this policy.
> >
> >> 3. The customer site must use the /32 to provide
> >
> >> IPv4 connectivity for hosts which have IPv6
> >
> >> addresses with IPv6 connectivity to the ISP/LIR.
> >
> >> 4. The ISP/LIR must demonstrate that it already
> >
> >> provides IPv6 addressing and connectivity to at
> >
> >> least one additional existing customer site for
> >
> >> each /32 requested, up to 90% of all customer sites
> >
> >> served (across all customers).
> >
> >> 5. An ISP/LIR customer which is not large enough to
> >
> >> qualify
> >
> >> under this provision and has no unassigned IPv4
> >
> >> addresses
> >
> >> may receive an appropriate number of /32s from their
> >
> >> upstream provider for reassignment to their customers
> >
> >> under the terms of 4.10.4(a).
> >
> >> 6. A customer site which terminates multiple connections
> >
> >> from the same provider on separate routers may
> >
> >> qualify
> >
> >> for one /32 per unique router with a direct
> >
> >> connection to
> >
> >> the provider, up to a total of 8 /32s.
> >
> >> 7. The total space issued to all organizations under
> >
> >> this provision shall not exceed an aggregate /9
> >
> >> or equivalent per /8 placed into the transition pool.
> >
> >>
> >
> >>
> >
> >> (b) An ISP/LIR or End user organization may request a block
> >
> >> no smaller than a /28 and no larger than a /18 per quarter
> >
> >> to provide single IPv4 /32s to each physical server used
> >
> >> to provide Internet reachable content.
> >
> >> 1. Space issued under this provision is an assignment,
> >
> >> not an allocation. An LIR may not distribute this
> >
> >> space to their customers.
> >
> >> 2. No server may receive more than a single IPv4 /32
> >
> >> under this provision.
> >
> >> 3. The server must have IPv6 addresses with IPv6
> >
> >> connectivity (must be dual-stacked).
> >
> >> 4. The receiving organization must demonstrate that it
> >
> >> already provides IPv6 addressing and connectivity
> >
> >> to at least one additional existing server
> >
> >> (organizations which can show 100% dual stack are
> >
> >> exempt from this requirement).
> >
> >> 5. The receiving organization must IPv6 enable all of
> >
> >> their content on the following schedule:
> >
> >>
> >
> >> + 25% of content IPv6 reachable within six
> >
> >> months of receiving their first addresses
> >
> >> under this policy
> >
> >> + 50% of content IPv6 reachable within one year
> >
> >> of receiving their first addresses under this
> >
> >> policy
> >
> >> + 75% of content IPv6 reachable within 18 months
> >
> >> of receiving their first addresses under this
> >
> >> policy
> >
> >> + 90% of content IPv6 reachable within 24 months
> >
> >> of receiving their first addresses under this
> >
> >> policy
> >
> >> 6. A network providing SSL terminations for applications
> >
> >> or content acceleration may receive a /32 for each
> >
> >> distinguished name by following all requirements in
> >
> >> this provision, substituting "distinguished name" for
> >
> >> "server."
> >
> >> 7. Networks using these addresses for authoritative
> >
> >> DNS servers can use 2 /32s per 1,000 authoritative
> >
> >> domains served up to 128 /32s total per organization.
> >
> >> 8. The total space issued to all organizations under
> >
> >> this provision shall not exceed an aggregate /9
> >
> >> or equivalent per /8 placed into the transition pool.
> >
> >>
> >
> >> (c) An ISP/LIR or End user organization may request a block no
> >
> >> smaller than a /29 and no larger than a /25 per quarter for
> >
> >> purposes relevant to their ability to deploy IPv6.
> >
> >> 1. Space issued under this provision is an assignment,
> >
> >> not an allocation. An LIR may not distribute this
> >
> >> space to their customers.
> >
> >> 2. Space issued under this provision must be used to
> >
> >> provide the required public IPv4 address(es) for
> >
> >> transitional technologies operated by the recipient
> >
> >> organization.
> >
> >>
> >
> >> Specific examples of permitted uses are:
> >
> >> a. Large scale or "Carrier Grade" NAT
> >
> >> b. NAT-PT
> >
> >> c. DS-LITE/B4/AFTeR
> >
> >> d. IVI
> >
> >> e. DNS64 or other transitional DNS enablers
> >
> >> f. Other technologies of similar purpose
> >
> >> and scope.
> >
> >>
> >
> >> 3. A /10 from the final /8 shall be reserved for
> >
> >> issuance
> >
> >> under this provision. In no case shall any addresses
> >
> >> from this /10 be issued for any purpose outside
> >
> >> of 4.10.4(c).
> >
> >>
> >
> >> (d) Applications which would qualify for IPv4 under section 4.4
> >
> >> of
> >
> >> the NRPM (critical infrastructure) may qualify for IPv4
> >
> >> space
> >
> >> under this policy if they meet the following criteria:
> >
> >> 1. The critical infrastructure to be numbered must also
> >
> >> have IPv6 addresses and must provide all services
> >
> >> provided on IPv4 over IPv6 on the same time table.
> >
> >> 2. Assignments under this provision shall be the
> >
> >> smallest technically feasible size for the critical
> >
> >> infrastructure in question.
> >
> >> 3. The total space assigned under this provision shall
> >
> >> not
> >
> >> exceed the equivalent of a /14.
> >
> >>
> >
> >> 
> > > >> > > > >>
> >
> >>
> >
> >>
> >
> >> Rationale:
> >
> >>
> >
> >> The current terminology in section 4.10 is vague and could allow a
> >
> >> variety of interpretations which could lead to allocations or
> >
> >> assignments being made to ISPs intending to misuse the space for
> >
> >> general deployment by using IPv6 overlay technologies as a "IPv6
> >
> >> deployments" requiring IPv4 space for transition. For example, the
> >
> >> current policy could be interpreted to enable an ISP to require IPv4
> >
> >> addresses for all IPv6 customers to roll IPv6 out as 6rd to customers
> >
> >> who would be otherwise unable to get IPv4 space. This is clearly
> >
> >> outside of the original intent of the proposal which created 4.10 (6rd
> >
> >> was not yet envisioned at the time that was written). This proposal
> >
> >> seeks to clarify that intent and tighten up the requirements for
> >
> >> organizations seeking to get space from this limited final resource so
> >
> >> that it truly is available to facilitate transitional technologies.
> >
> >>
> >
> >> Additionally, there are a number of community segments that are not
> >
> >> well served by the original intent of 4.10 and several community
> >
> >> members requested a mechanism for providing a certain amount of
> >
> >> certainty with regards to obtaining space at the end. While it would be
> >
> >> impossible to guarantee organizations all the space they need as runout
> >
> >> is upon us, this policy seeks to provide a way for organizations to
> >
> >> sign up for and receive a reservation from the final space
> >
> >> proportionate to their need. The policy also includes guidelines
> >
> >> intended to ensure that this vital community resource is given only to
> >
> >> organizations working towards a smooth transition to IPv6 to the
> >
> >> benefit of the full community.
> >
> >>
> >
> >> In order to meet these needs, this policy has become very complex. It
> >
> >> is an unfortunate artifact of the complex issue it seeks to address. A
> >
> >> great deal of effort has been made to simplify the policy as much as
> >
> >> possible, and, special thinks go out to several members of the
> >
> >> community for their assistance in this matter.
> >
> >>
> >
> >> One provision in this draft policy calls for utilization criteria which
> >
> >> may be waived by ARIN staff discretion. The intent of this clause is to
> >
> >> allow staff to avoid penalizing an organization for successful address
> >
> >> conservation efforts.
> >
> >>
> >
> >> Runout is upon us. IANA will run out of the IANA free pool and issue
> >
> >> the last /8 this policy seeks to regulate before the next ARIN public
> >
> >> policy meeting. If we are to make any attempt at fair distribution for
> >
> >> the sake of IPv6 deployment, this is our final opportunity to do so
> >
> >> outside of an emergency action by the ARIN board.
> >
> >>
> >
> >> Timetable for implementation: immediate
> >
> >>
> >
> >> For reference, here is the current text of 4.10
> >
> >>
> >
> >> 4.10 Dedicated IPv4 block to facilitate IPv6 Deployment
> >
> >>
> >
> >> When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous
> >
> >> /10 IPv4 block will be set aside and dedicated to facilitate IPv6
> >
> >> deployment. Allocations and assignments from this block must be
> >
> >> justified by immediate IPv6 deployment requirements. Examples of such
> >
> >> needs include: IPv4 addresses for key dual stack DNS servers, and NAT-
> >
> >> PT or NAT464 translators. ARIN staff will use their discretion when
> >
> >> evaluating justifications.
> >
> >>
> >
> >> This block will be subject to a minimum size allocation of /28 and a
> >
> >> maximum size allocation of /24. ARIN should use sparse allocation when
> >
> >> possible within that /10 block.
> >
> >>
> >
> >> In order to receive an allocation or assignment under this policy:
> >
> >> 1. the applicant may not have received resources under this
> >
> >> policy in the preceding six months;
> >
> >> 2. previous allocations/assignments under this policy must
> >
> >> continue to meet the justification requirements of this policy;
> >
> >> 3. previous allocations/assignments under this policy must meet
> >
> >> the utilization requirements of end user assignments;
> >
> >> 4. the applicant must demonstrate that no other allocations or
> >
> >> assignments will meet this need;
> >
> >> 5. on subsequent allocation under this policy, ARIN staff may
> >
> >> require applicants to renumber out of previously allocated / assigned
> >
> >> space under this policy in order to minimize non-contiguous
> >
> >> allocations.
> >
> >
> >
> >
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 29 Sep 2010 08:32:59 -0600
> From: Chris Grundemann 
> To: "arin-ppml at arin.net" 
> Subject: Re: [arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55)
> Message-ID:
>        
> Content-Type: text/plain; charset=windows-1252
>
> I think the fact that ARIN Staff is concerned that this policy may
> favor organizations who are granted reservations too much and Marty
> believes that it does not go far enough to provide relief to those
> same organizations illustrates that we have actually found a pretty
> decent compromise.
>
> On Tue, Sep 28, 2010 at 15:55, Hannigan, Martin  wrote:
> >
> > This proposal still does not go far enough in offering some level of
> relief
> > to all segments of the industry.
>
> The simple fact is that we are running out of IPv4 space. Absolutely
> no policy can change that. Advancing transition to IPv6 across the
> board is the best way (perhaps the only way) to ease all of our
> growing pains going forward.
>
> > On 9/27/10 4:02 PM, "ARIN"  wrote:
> >>
> >> ? A. ? ?ARIN Staff Comments
> >>
> >> ? ?? Section 4.10.2 suggests that all allocations made under this policy
> >> will initially be made from a 3-year reservation. ?In light of the
> >> imminent depletion of IPv4 address space, it doesn't seem fair to allow
> >> some organizations to retain/reserve this valuable resource for up to 3
> >> years while others will be denied.
>
> I would like to point out that although the initial reservations are
> for [now two years], there is a built in "fairness valve" as well.
> Please see section 4.10.2.1 in the draft policy, which starts thus:
>
>        Reservations will be accepted from the time that this policy
>        is adopted until the day that ARIN can no longer fill regular
> requests from
>        space allocated to ARIN by IANA. At that time, if necessary, all
> reservations
>        will be reduced by an equal amount to allow them to fit within
>        the total space available in the transition pool.
>
> So everyone who is granted a reservation before run-out gets *some*
> reservation, although it is not likely that anyone will get the full
> reservation requested. I think this is the best balance of
> predictability and inclusiveness possible.
>
> Also note the second phase, post-exhaustion, detailed in section
> 4.10.2.2 which reads:
>
>        Reservation requests received after ARIN free pool depletion
>        as defined in 4.10.2.1 will not be guaranteed. If approved, such
>        requests will be placed in a queue. As space becomes available in
>        the transition pool it will be used to provide allotments to
>        organizations with reservations in the queue on a first-approved
>        first-served basis. Partially filled allotments will remain at the
>        front of the queue.
>
> So, *everyone* gets a shot at the transition space, and it comes down
> to how much space ends up being available.
>
> Overall, I think we have come up with the best possible (most fair)
> soft-landing policy under the current constraints (constraints which
> will only get tighter).
>
> ~Chris
>
> >>
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> >
>
> --
> @ChrisGrundemann
> weblog.chrisgrundemann.com
> www.burningwiththebush.com
> www.coisoc.org
>
>
> ------------------------------
>
> _______________________________________________
> ARIN-PPML mailing list
> ARIN-PPML at arin.net
> http://lists.arin.net/mailman/listinfo/arin-ppml
>
> End of ARIN-PPML Digest, Vol 63, Issue 32
> *****************************************
>



-- 

Rudi Daniel
*danielcharles consulting
**1-784 498 8277
*
*
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From bicknell at ufp.org  Wed Sep 29 11:16:55 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 29 Sep 2010 08:16:55 -0700
Subject: [arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55)
In-Reply-To: <28B1812C-FBCF-4EED-94CD-14FF2DBC4869@delong.com>
References: <28B1812C-FBCF-4EED-94CD-14FF2DBC4869@delong.com>
Message-ID: <20100929151655.GA1763@ussenterprise.ufp.org>

In a message written on Thu, Sep 23, 2010 at 04:26:05PM -0700, Owen DeLong wrote:
> Subject: [arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55)

[a line or two of text removed]

I have no idea how this policy got to 55 revisions (I missed some
of the middle discussion), that's not a good sign.

I read it, twice, top to bottom, and stopped to think about it for
a few minutes.  I have no specific feedback because I honestly have
no way to evaluate the policy.  It is extremely difficult to wrap
your head around in total, and largely affects events in the future
that are quite uncertain at this point.

I think a large part of the ARIN community wants to have all the
details of an IPv4->IPv6 transition figured out before IPv4 runs
out.  A noble goal, and to the extent that is possible it should
be done.  It is important to realize though, it is not possible.
How folks react during this time period, which transition technologies
get used, how much space they need to make them go and a lot of
other details will be shaped by events yet to come, and that may
be strongly influenced by outside forces.  For instance 6to4 has
more momentum from CPE vendors placing it in boxes than from any
operator wanting to run it as a transition mechanism, and CPE vendors
aren't generally looking to ARIN for guidance.

I think the community would be much better served by waiting.
Unfortunately much like a kid in a candy shop this is a very hard
thing to do, and takes a huge amount of will power.  Basically
nothing should be given out under 4.10 until it's clear what the
right thing to do is, in simple language.  If that means we need 6
months where there is no more IPv4 and nothing given out under 4.10
so the world feels enough pain to come to a common consensus, so
be it.  It's far more important to make the last /10 the most
effective /10 ever allocated, rather than trying to be sure that
we have the "solution" ready to go on day 1.

I don't support the policy.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: 

From owen at delong.com  Wed Sep 29 11:36:17 2010
From: owen at delong.com (Owen DeLong)
Date: Wed, 29 Sep 2010 08:36:17 -0700
Subject: [arin-ppml] ARIN-PPML Digest, Vol 63, Issue 32
In-Reply-To: 
References: 
	
Message-ID: <17ECD436-9BD6-4F87-B445-3BEF24D91A58@delong.com>

Rudy,
	The reason for the detailed criteria is to preserve these specific
final addresses in support of IPv6 transition rather than further consumption
under the business as usual rules.

	The alternative, of course, is to leave policy as it is, consuming
the few remaining IPv4 addresses under the current system with
virtually nothing set aside to facilitate transition to IPv6 other than
a very limited subset of technologies specified in the existing 4.10.

Owen

On Sep 29, 2010, at 7:49 AM, Rudolph Daniel wrote:

> I cannot support 2010-13 presently because it still seems to me to be overtly complex prone to misunderstanding.
> 
> One example: >ISPs can apply for /32s for customers as long as each customer
> > meets the policy's detailed qualification criteria. As an ISP, I may not be too happy imposing detailed qualification criteria which will be a beyond my commercial requirement and may simply frustrate and complicate the process at all levels.
> 
> Rudi Daniel
> 
> 
> 
> On Wed, Sep 29, 2010 at 10:33 AM,  wrote:
> Send ARIN-PPML mailing list submissions to 
>        arin-ppml at arin.net
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://lists.arin.net/mailman/listinfo/arin-ppml
> or, via email, send a message with subject or body 'help' to
>        arin-ppml-request at arin.net
> 
> You can reach the person managing the list at
>        arin-ppml-owner at arin.net
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ARIN-PPML digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: Final draft of 2010-13 for Atlanta (Rev 1.55)
>      (Hannigan, Martin)
>   2. Re: Final draft of 2010-13 for Atlanta (Rev 1.55)
>      (Chris Grundemann)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue, 28 Sep 2010 17:55:37 -0400
> From: "Hannigan, Martin" 
> To: "arin-ppml at arin.net" 
> Subject: Re: [arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55)
> Message-ID: 
> Content-Type: text/plain; charset="Windows-1252"
> 
> 
> 
> I oppose this proposal. I think it's destructive; it's complicated and fails
> to establish any leadership and it's divisive; the reservation system and
> classes of requests create significant inequities for all that have need. It
> fails to allow anyone to plan. The end result is that we're going to pit all
> of our members against each other in open markets. Regardless of this
> proposal, that may happen still. When I supported the petition I had hoped
> that we could stretch this remaining space and provide some relief and
> define what's important with regards to continuing to grow the net while we
> transition. That is impossible with this proposal and perhaps impossible
> with any proposal and a single /8[1]. [ The recent CableLabs Draft is very
> interesting FWIW]
> 
> This proposal still does not go far enough in offering some level of relief
> to all segments of the industry. I concur with the staff comments related
> and specifically comments related to the complexity.
> 
> I did support "the concept" of the reservation system with different terms
> and provider relief with respect to CPE et. Al. The proposal fails to
> explain itself adequately with respect to both and if it were adequately
> explained it may seem less unfair if it were re-written. Transition not be
> without pain and some of us are already challenged by it.
> 
> I don't have a suggestion other than a complete rewrite which is why I
> support completely abandoning it.
> 
> 
> Best,
> 
> -M<
> 
> 
> 
> 1. http://tools.ietf.org/html/draft-weil-opsawg-provider-address-space-00
> 
> 
> 
> 
> 
> 
> On 9/27/10 4:02 PM, "ARIN"  wrote:
> 
> > Draft Policy 2010-13
> > Permitted Uses of space reserved under NRPM 4.10
> >
> > Attached is the ARIN staff assessment of 2010-13. We assessed the 1.53
> > version of the draft policy (it's currently at 1.55). It is noted that
> > the time frame for reserves has been reduced from 36 to 24 months in
> > version 1.55.
> >
> > This draft policy is open for discussion on this mailing list and will
> > be on the agenda at the upcoming ARIN Public Policy Meeting in Atlanta.
> >
> > 2010-13 is below and available at:
> > https://www.arin.net/policy/proposals/2010_13.html
> >
> > Regards,
> >
> > Communications and Member Services
> > American Registry for Internet Numbers (ARIN)
> >
> >
> > ## * ##
> >
> >
> > Staff Assessment of Draft Policy 2010-13 (version 1.53 dated 19
> > September 2010)
> >
> > Permitted Uses of space reserved under NRPM 4.10
> >
> > 1. Proposal Summary (Staff Understanding)
> >
> > This policy modifies the existing NRPM policy 4.10 (?Dedicated IPv4
> > block to facilitate IPv6 Deployment?).  It sets aside in its entirety
> > the last /8 ARIN receives from the IANA for issuance to networks
> > transitioning to a dual IPv4/IPv6 network rather than the /10 currently
> > cited in NRPM 4.10. Any IPv4 address space returned to ARIN (and not
> > subject to a global or regional transfer policy) will be added to this
> > transition pool.  Under this policy there are four major classes of
> > requestors:
> >
> >    - ISPs can apply for /32s for customers as long as each customer
> > meets the policy's detailed qualification criteria.
> >
> >    - Any operator can apply for /32s for issuing to devices used to
> > serve-up internet facing content, within the constraints of the defined
> > qualifying criteria.
> >
> >    - From the /8, a /10 will be set aside so that any operator can
> > request space for use in infrastructure numbering for the purposes of
> > deploying IPv6. Space can be issued from this /8 for applicants who
> > qualify under ARIN's Micro-allocation Policy (with additional
> > restrictions).
> >
> >    - Finally, space can be issued from this /8 for applicants who
> > operate content distribution networks, again, within the context of the
> > policy's qualifying criteria.
> >
> > Organizations can request address space to meet their 3-year needs.
> > Space is allocated/assigned in quarterly installments.  After the first
> > quarter, the requestor can only return to ARIN if they have utilized 80%
> > of the most recent assignment, and 90% of past assignments (issued under
> > this policy). The organization must have also assigned all IP addresses
> > issued under the policy to uses that are acceptable under the policy.
> > If the organization fails to meet the utilization criteria for four
> > consecutive quarters, then the policy directs ARIN staff to reduce the
> > amount of space reserved.
> >
> > 2. Comments
> >
> >   A.    ARIN Staff Comments
> >
> >    ? The policy text has become very complex and complicated and the
> > general community will have a very hard time understanding the concepts
> > and criteria proposed within the policy.
> >
> >    ? It seems to be out of order ? it starts out with reservations
> > before ever mentioning the initial qualifying criteria.  The author
> > might want to consider re-ordering to start with the essential
> > qualification criteria first.
> >
> >    ? Section 4.10.2 suggests that all allocations made under this policy
> > will initially be made from a 3-year reservation.  In light of the
> > imminent depletion of IPv4 address space, it doesn't seem fair to allow
> > some organizations to retain/reserve this valuable resource for up to 3
> > years while others will be denied.
> >
> >    ? The policy text in (in 4.10.3) appears to contradict itself, as it
> > first directs staff to remove one quarter's worth of reservation, and
> > then, if the organization continues this practice for three consecutive
> > quarters, remove the organization's reserves completely. Later, it
> > explicitly directs staff to revoke addresses issued under this policy
> > that are used by the organizations for purposes not permitted under this
> > policy.
> >
> >    ? This proposal will essentially supplant the recently ratified
> > policy "Waiting List for Unmet Resources". That list will consist of
> > people waiting for resources to be returned or revoked so that ARIN can
> > then reissue them to requestors in need of IPv4 address space.  This
> > proposal says that any IPv4 address space that comes back to ARIN
> > immediately goes into the IPv6 transition pool and can only be used for
> > that purpose.
> >
> >    ? Under 4.10.4.B5, how would staff be able to verify that x percent
> > of an organization?s content is IPv6 reachable?
> >
> >
> >   B. ARIN General Counsel
> > This policy is unlikely to cause any legal issues of any importance.
> >
> >
> > 3. Resource Impact
> >
> > This policy would have moderate to major resource impact.  It is
> > estimated that implementation would occur within 6 to 9 months after
> > ratification by the ARIN Board of Trustees. The following would be
> > needed in order to implement:
> >    ? Changes to the way ARIN manages reverse DNS (to handle in-addr.arpa
> > delegations for blocks smaller than /24)
> >    ? Updated guidelines
> >    ? Staff training
> >
> >
> >> -----Original Message-----
> >
> >> From: Owen DeLong [mailto:owen at delong.com]
> >
> >> Sent: Thursday, September 23, 2010 7:26 PM
> >
> >> To: arin-ppml at arin.net List; policy
> >
> >> Subject: Final draft of 2010-13 for Atlanta (Rev 1.55)
> >
> >>
> >
> >> Changes:
> >
> >>
> >
> >> 1. Set maximum reservation period to 24 months. This avoids creating
> >
> >> a 4-year reservation by CIDR-rounding 36 month reservations.
> >
> >> 2. Reduced minimum size for 4.10.4(b) to /28
> >
> >>
> >
> >> These changes will make the policy more balanced and reduce the extent
> >
> >> to
> >
> >> which larger organizations could be disadvantaged relative to smaller
> >
> >> smaller organizations if reservations have to be resized.
> >
> >>
> >
> >> The change to a 2-year system resolves an issue with the CIDR-Rounding
> >
> >> where a 36-month reservation is mathematically guaranteed to become a
> >
> >> 48-month reservation. The other alternative was to round-down instead
> >
> >> of
> >
> >> up which would have mathematically converted all reservations to 2
> >
> >> years.
> >
> >> As such, a 2-year reservation system seemed the cleanest and most
> >
> >> straightforward approach.
> >
> >>
> >
> >> Owen
> >
> >>
> >
> >> Draft Policy 2010-13: Permitted Uses of Space Reserved under NRPM 4.10
> >
> >> Proposal Originator: Owen DeLong, Chris Grundemann
> >
> >> Proposal Version: 1.55
> >
> >> Date: 23 September 2010
> >
> >> Proposal type: modify
> >
> >> Policy term: permanent
> >
> >> Policy statement:
> >
> >>
> >
> >> Remove section 4.1.8 (Unmet requests) from the NRPM.
> >
> >> Replace the text of section 4.10 in its entirety (including the name)
> >
> >> with:
> >
> >>
> >
> >> 4.10 IPv4 Transition Pool Post IANA Regular Pool Depletion
> >
> >>
> >
> >> When ARIN receives its /8 IPv4 allocation from IANA under the
> >
> >> global policy titled "Global Policy for the Allocation of the
> >
> >> Remaining IPv4 Address Space" ratified by ICANN Board
> >
> >> on 6 March, 2009, that /8 will form a dedicated pool to
> >
> >> facilitate IPv6 Deployment.
> >
> >>
> >
> >> Addresses returned to ARIN and not subject to a regional or
> >
> >> global transfer policy will be reserved for utilization in the
> >
> >> transition
> >
> >> pool.
> >
> >>
> >
> >> Allocations and assignments from this block must be justified by
> >
> >> IPv6 transition requirements.
> >
> >>
> >
> >> ARIN will use their discretion in determining whether a
> >
> >> particular
> >
> >> application meets the spirit of this policy.
> >
> >>
> >
> >> 4.10.1 Addressing Plan
> >
> >>
> >
> >> Any organization wishing to receive IPv4 addresses through this
> >
> >> policy must submit a detailed addressing plan for any request
> >
> >> that is made containing the following:
> >
> >> (a) Their addressing needs over the entire reservation period
> >
> >> and
> >
> >> (b) Methods of meeting all requirements (requirements are
> >
> >> explained in section 4.10.4.) over the entire reservation
> >
> >> period.
> >
> >>
> >
> >> 4.10.2 Reservation System
> >
> >>
> >
> >> Initially, all space assigned or allocated under this policy will
> >
> >> be
> >
> >> reserved in advance for a maximum period of 24 months, requests
> >
> >> for
> >
> >> shorter reservations will be accepted. The total reservation size
> >
> >> will be rounded up to a CIDR bit boundary.
> >
> >>
> >
> >> Each organization's reservation amount will be divided
> >
> >> into quarterly allotments. Allotments will be rounded up
> >
> >> to a CIDR bit boundary. The final quarterly allotment will
> >
> >> contain only the remaining space from the full reservation.
> >
> >>
> >
> >> An organization may request one reservation under each provision
> >
> >> listed in section 4.10.4. Once a reservation has been satisfied,
> >
> >> another may be requested.
> >
> >>
> >
> >> 4.10.2.1 Reservation Requests Prior to Initial ARIN Free Pool
> >
> >> Depletion
> >
> >>
> >
> >> Reservations will be accepted from the time that this policy
> >
> >> is adopted until the day that ARIN can no longer fill regular
> >
> >> requests from
> >
> >> space allocated to ARIN by IANA. At that time, if necessary, all
> >
> >> reservations
> >
> >> will be reduced by an equal amount to allow them to fit within
> >
> >> the total space available in the transition pool. No reservation
> >
> >> will be reduced lower than the minimum quarterly allotment for
> >
> >> it's category. Each organization may decide whether to adjust
> >
> >> the reservation period or the allotment size (within the stated
> >
> >> range) when reservations are reduced. Organizations must make
> >
> >> this decision within 30 days of announcement and may not alter
> >
> >> their choice once made. Any space added to the transition
> >
> >> pool during this time will cause a final recalculation of
> >
> >> reservation sizes. Once all necessary adjustments are
> >
> >> made, all reservations are guaranteed and the first quarterly
> >
> >> allotment is issued to each org.
> >
> >>
> >
> >> 4.10.2.2 Reservation Requests Post ARIN Free Pool Depletion
> >
> >>
> >
> >> Reservation requests received after ARIN free pool depletion
> >
> >> as defined in 4.10.2.1 will not be guaranteed. If approved, such
> >
> >> requests will be placed in a queue. As space becomes available in
> >
> >> the transition pool it will be used to provide allotments to
> >
> >> organizations with reservations in the queue on a first-approved
> >
> >> first-served basis. Partially filled allotments will remain at
> >
> >> the
> >
> >> front of the queue.
> >
> >>
> >
> >> 4.10.2.3 Abandonment of Reservation
> >
> >>
> >
> >> Any organization may abandon their remaining reservation at any
> >
> >> time by informing ARIN of their desire to do so. Upon
> >
> >> abandonment,
> >
> >> the remaining space in the reservation will be returned to the
> >
> >> transition pool.
> >
> >>
> >
> >> 4.10.3 Quarterly Requirements
> >
> >>
> >
> >> Organizations with approved reservations and address plans
> >
> >> are entitled to quarterly allotments. In order to receive each
> >
> >> additional allotment, an organization must submit evidence of
> >
> >> compliance with the following sub-sections:
> >
> >> (a) The most recent 4.10 allotment is at least 80% utilized.
> >
> >> (b) All prior 4.10 allotments within the same 4.10.4
> >
> >> category are at least 90% utilized.
> >
> >> (c) All utilization is permitted under the 4.10.4 category for
> >
> >> which it was initially requested.
> >
> >>
> >
> >> For purposes of this computation, space received under each
> >
> >> provision shall be considered separately if an organization has
> >
> >> received resources through multiple provisions.
> >
> >>
> >
> >> If an organization does not meet all obligations in any given
> >
> >> quarter, that organization shall not receive that quarter's
> >
> >> allotment
> >
> >> and shall have their reservation reduced by one quarterly
> >
> >> allotment.
> >
> >> If an organization does not meet all obligations
> >
> >> for three consecutive quarters, that organization forfeits the
> >
> >> remainder
> >
> >> of their reserved block.
> >
> >>
> >
> >> Utilization requirements (a) may be delayed at ARIN's discretion.
> >
> >>
> >
> >> If an organization is using space received under 4.10 in a manner
> >
> >> contrary to 4.10, that organization forfeits their remaining
> >
> >> reservation and may have their entire allocation or assignment
> >
> >> revoked.
> >
> >>
> >
> >> All 4.10. space forfeited, revoked or otherwise reclaimed shall
> >
> >> be returned to the ARIN transition pool.
> >
> >>
> >
> >> 4.10.4 Specific types of transitional uses have specific
> >
> >> requirements:
> >
> >>
> >
> >> (a) An ISP/LIR may request a block no smaller than a /25 nor
> >
> >> larger than a /18 per quarter to be used to provide single
> >
> >> IPv4 /32s to their customers which could justify a /28 or
> >
> >> more of IPv4 under ARIN policies in effect at the time of
> >
> >> IANA depletion.
> >
> >> 1. No customer site may receive more than a single
> >
> >> IPv4 /32 per 1,000 Internet connected hosts upto 8
> >
> >> /32s.
> >
> >> 2. The customer site must not have any IPv4
> >
> >> addresses not issued under this policy.
> >
> >> 3. The customer site must use the /32 to provide
> >
> >> IPv4 connectivity for hosts which have IPv6
> >
> >> addresses with IPv6 connectivity to the ISP/LIR.
> >
> >> 4. The ISP/LIR must demonstrate that it already
> >
> >> provides IPv6 addressing and connectivity to at
> >
> >> least one additional existing customer site for
> >
> >> each /32 requested, up to 90% of all customer sites
> >
> >> served (across all customers).
> >
> >> 5. An ISP/LIR customer which is not large enough to
> >
> >> qualify
> >
> >> under this provision and has no unassigned IPv4
> >
> >> addresses
> >
> >> may receive an appropriate number of /32s from their
> >
> >> upstream provider for reassignment to their customers
> >
> >> under the terms of 4.10.4(a).
> >
> >> 6. A customer site which terminates multiple connections
> >
> >> from the same provider on separate routers may
> >
> >> qualify
> >
> >> for one /32 per unique router with a direct
> >
> >> connection to
> >
> >> the provider, up to a total of 8 /32s.
> >
> >> 7. The total space issued to all organizations under
> >
> >> this provision shall not exceed an aggregate /9
> >
> >> or equivalent per /8 placed into the transition pool.
> >
> >>
> >
> >>
> >
> >> (b) An ISP/LIR or End user organization may request a block
> >
> >> no smaller than a /28 and no larger than a /18 per quarter
> >
> >> to provide single IPv4 /32s to each physical server used
> >
> >> to provide Internet reachable content.
> >
> >> 1. Space issued under this provision is an assignment,
> >
> >> not an allocation. An LIR may not distribute this
> >
> >> space to their customers.
> >
> >> 2. No server may receive more than a single IPv4 /32
> >
> >> under this provision.
> >
> >> 3. The server must have IPv6 addresses with IPv6
> >
> >> connectivity (must be dual-stacked).
> >
> >> 4. The receiving organization must demonstrate that it
> >
> >> already provides IPv6 addressing and connectivity
> >
> >> to at least one additional existing server
> >
> >> (organizations which can show 100% dual stack are
> >
> >> exempt from this requirement).
> >
> >> 5. The receiving organization must IPv6 enable all of
> >
> >> their content on the following schedule:
> >
> >>
> >
> >> + 25% of content IPv6 reachable within six
> >
> >> months of receiving their first addresses
> >
> >> under this policy
> >
> >> + 50% of content IPv6 reachable within one year
> >
> >> of receiving their first addresses under this
> >
> >> policy
> >
> >> + 75% of content IPv6 reachable within 18 months
> >
> >> of receiving their first addresses under this
> >
> >> policy
> >
> >> + 90% of content IPv6 reachable within 24 months
> >
> >> of receiving their first addresses under this
> >
> >> policy
> >
> >> 6. A network providing SSL terminations for applications
> >
> >> or content acceleration may receive a /32 for each
> >
> >> distinguished name by following all requirements in
> >
> >> this provision, substituting "distinguished name" for
> >
> >> "server."
> >
> >> 7. Networks using these addresses for authoritative
> >
> >> DNS servers can use 2 /32s per 1,000 authoritative
> >
> >> domains served up to 128 /32s total per organization.
> >
> >> 8. The total space issued to all organizations under
> >
> >> this provision shall not exceed an aggregate /9
> >
> >> or equivalent per /8 placed into the transition pool.
> >
> >>
> >
> >> (c) An ISP/LIR or End user organization may request a block no
> >
> >> smaller than a /29 and no larger than a /25 per quarter for
> >
> >> purposes relevant to their ability to deploy IPv6.
> >
> >> 1. Space issued under this provision is an assignment,
> >
> >> not an allocation. An LIR may not distribute this
> >
> >> space to their customers.
> >
> >> 2. Space issued under this provision must be used to
> >
> >> provide the required public IPv4 address(es) for
> >
> >> transitional technologies operated by the recipient
> >
> >> organization.
> >
> >>
> >
> >> Specific examples of permitted uses are:
> >
> >> a. Large scale or "Carrier Grade" NAT
> >
> >> b. NAT-PT
> >
> >> c. DS-LITE/B4/AFTeR
> >
> >> d. IVI
> >
> >> e. DNS64 or other transitional DNS enablers
> >
> >> f. Other technologies of similar purpose
> >
> >> and scope.
> >
> >>
> >
> >> 3. A /10 from the final /8 shall be reserved for
> >
> >> issuance
> >
> >> under this provision. In no case shall any addresses
> >
> >> from this /10 be issued for any purpose outside
> >
> >> of 4.10.4(c).
> >
> >>
> >
> >> (d) Applications which would qualify for IPv4 under section 4.4
> >
> >> of
> >
> >> the NRPM (critical infrastructure) may qualify for IPv4
> >
> >> space
> >
> >> under this policy if they meet the following criteria:
> >
> >> 1. The critical infrastructure to be numbered must also
> >
> >> have IPv6 addresses and must provide all services
> >
> >> provided on IPv4 over IPv6 on the same time table.
> >
> >> 2. Assignments under this provision shall be the
> >
> >> smallest technically feasible size for the critical
> >
> >> infrastructure in question.
> >
> >> 3. The total space assigned under this provision shall
> >
> >> not
> >
> >> exceed the equivalent of a /14.
> >
> >>
> >
> >> 
> > > >> > > > >>
> >
> >>
> >
> >>
> >
> >> Rationale:
> >
> >>
> >
> >> The current terminology in section 4.10 is vague and could allow a
> >
> >> variety of interpretations which could lead to allocations or
> >
> >> assignments being made to ISPs intending to misuse the space for
> >
> >> general deployment by using IPv6 overlay technologies as a "IPv6
> >
> >> deployments" requiring IPv4 space for transition. For example, the
> >
> >> current policy could be interpreted to enable an ISP to require IPv4
> >
> >> addresses for all IPv6 customers to roll IPv6 out as 6rd to customers
> >
> >> who would be otherwise unable to get IPv4 space. This is clearly
> >
> >> outside of the original intent of the proposal which created 4.10 (6rd
> >
> >> was not yet envisioned at the time that was written). This proposal
> >
> >> seeks to clarify that intent and tighten up the requirements for
> >
> >> organizations seeking to get space from this limited final resource so
> >
> >> that it truly is available to facilitate transitional technologies.
> >
> >>
> >
> >> Additionally, there are a number of community segments that are not
> >
> >> well served by the original intent of 4.10 and several community
> >
> >> members requested a mechanism for providing a certain amount of
> >
> >> certainty with regards to obtaining space at the end. While it would be
> >
> >> impossible to guarantee organizations all the space they need as runout
> >
> >> is upon us, this policy seeks to provide a way for organizations to
> >
> >> sign up for and receive a reservation from the final space
> >
> >> proportionate to their need. The policy also includes guidelines
> >
> >> intended to ensure that this vital community resource is given only to
> >
> >> organizations working towards a smooth transition to IPv6 to the
> >
> >> benefit of the full community.
> >
> >>
> >
> >> In order to meet these needs, this policy has become very complex. It
> >
> >> is an unfortunate artifact of the complex issue it seeks to address. A
> >
> >> great deal of effort has been made to simplify the policy as much as
> >
> >> possible, and, special thinks go out to several members of the
> >
> >> community for their assistance in this matter.
> >
> >>
> >
> >> One provision in this draft policy calls for utilization criteria which
> >
> >> may be waived by ARIN staff discretion. The intent of this clause is to
> >
> >> allow staff to avoid penalizing an organization for successful address
> >
> >> conservation efforts.
> >
> >>
> >
> >> Runout is upon us. IANA will run out of the IANA free pool and issue
> >
> >> the last /8 this policy seeks to regulate before the next ARIN public
> >
> >> policy meeting. If we are to make any attempt at fair distribution for
> >
> >> the sake of IPv6 deployment, this is our final opportunity to do so
> >
> >> outside of an emergency action by the ARIN board.
> >
> >>
> >
> >> Timetable for implementation: immediate
> >
> >>
> >
> >> For reference, here is the current text of 4.10
> >
> >>
> >
> >> 4.10 Dedicated IPv4 block to facilitate IPv6 Deployment
> >
> >>
> >
> >> When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous
> >
> >> /10 IPv4 block will be set aside and dedicated to facilitate IPv6
> >
> >> deployment. Allocations and assignments from this block must be
> >
> >> justified by immediate IPv6 deployment requirements. Examples of such
> >
> >> needs include: IPv4 addresses for key dual stack DNS servers, and NAT-
> >
> >> PT or NAT464 translators. ARIN staff will use their discretion when
> >
> >> evaluating justifications.
> >
> >>
> >
> >> This block will be subject to a minimum size allocation of /28 and a
> >
> >> maximum size allocation of /24. ARIN should use sparse allocation when
> >
> >> possible within that /10 block.
> >
> >>
> >
> >> In order to receive an allocation or assignment under this policy:
> >
> >> 1. the applicant may not have received resources under this
> >
> >> policy in the preceding six months;
> >
> >> 2. previous allocations/assignments under this policy must
> >
> >> continue to meet the justification requirements of this policy;
> >
> >> 3. previous allocations/assignments under this policy must meet
> >
> >> the utilization requirements of end user assignments;
> >
> >> 4. the applicant must demonstrate that no other allocations or
> >
> >> assignments will meet this need;
> >
> >> 5. on subsequent allocation under this policy, ARIN staff may
> >
> >> require applicants to renumber out of previously allocated / assigned
> >
> >> space under this policy in order to minimize non-contiguous
> >
> >> allocations.
> >
> >
> >
> >
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Wed, 29 Sep 2010 08:32:59 -0600
> From: Chris Grundemann 
> To: "arin-ppml at arin.net" 
> Subject: Re: [arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55)
> Message-ID:
>        
> Content-Type: text/plain; charset=windows-1252
> 
> I think the fact that ARIN Staff is concerned that this policy may
> favor organizations who are granted reservations too much and Marty
> believes that it does not go far enough to provide relief to those
> same organizations illustrates that we have actually found a pretty
> decent compromise.
> 
> On Tue, Sep 28, 2010 at 15:55, Hannigan, Martin  wrote:
> >
> > This proposal still does not go far enough in offering some level of relief
> > to all segments of the industry.
> 
> The simple fact is that we are running out of IPv4 space. Absolutely
> no policy can change that. Advancing transition to IPv6 across the
> board is the best way (perhaps the only way) to ease all of our
> growing pains going forward.
> 
> > On 9/27/10 4:02 PM, "ARIN"  wrote:
> >>
> >> ? A. ? ?ARIN Staff Comments
> >>
> >> ? ?? Section 4.10.2 suggests that all allocations made under this policy
> >> will initially be made from a 3-year reservation. ?In light of the
> >> imminent depletion of IPv4 address space, it doesn't seem fair to allow
> >> some organizations to retain/reserve this valuable resource for up to 3
> >> years while others will be denied.
> 
> I would like to point out that although the initial reservations are
> for [now two years], there is a built in "fairness valve" as well.
> Please see section 4.10.2.1 in the draft policy, which starts thus:
> 
>        Reservations will be accepted from the time that this policy
>        is adopted until the day that ARIN can no longer fill regular requests from
>        space allocated to ARIN by IANA. At that time, if necessary, all reservations
>        will be reduced by an equal amount to allow them to fit within
>        the total space available in the transition pool.
> 
> So everyone who is granted a reservation before run-out gets *some*
> reservation, although it is not likely that anyone will get the full
> reservation requested. I think this is the best balance of
> predictability and inclusiveness possible.
> 
> Also note the second phase, post-exhaustion, detailed in section
> 4.10.2.2 which reads:
> 
>        Reservation requests received after ARIN free pool depletion
>        as defined in 4.10.2.1 will not be guaranteed. If approved, such
>        requests will be placed in a queue. As space becomes available in
>        the transition pool it will be used to provide allotments to
>        organizations with reservations in the queue on a first-approved
>        first-served basis. Partially filled allotments will remain at the
>        front of the queue.
> 
> So, *everyone* gets a shot at the transition space, and it comes down
> to how much space ends up being available.
> 
> Overall, I think we have come up with the best possible (most fair)
> soft-landing policy under the current constraints (constraints which
> will only get tighter).
> 
> ~Chris
> 
> >>
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> >
> 
> --
> @ChrisGrundemann
> weblog.chrisgrundemann.com
> www.burningwiththebush.com
> www.coisoc.org
> 
> 
> ------------------------------
> 
> _______________________________________________
> ARIN-PPML mailing list
> ARIN-PPML at arin.net
> http://lists.arin.net/mailman/listinfo/arin-ppml
> 
> End of ARIN-PPML Digest, Vol 63, Issue 32
> *****************************************
> 
> 
> 
> -- 
> 
> Rudi Daniel
> danielcharles consulting
> 1-784 498 8277
> 
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From cgrundemann at gmail.com  Wed Sep 29 11:42:34 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Wed, 29 Sep 2010 09:42:34 -0600
Subject: [arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55)
In-Reply-To: <20100929151655.GA1763@ussenterprise.ufp.org>
References: <28B1812C-FBCF-4EED-94CD-14FF2DBC4869@delong.com>
	<20100929151655.GA1763@ussenterprise.ufp.org>
Message-ID: 

On Wed, Sep 29, 2010 at 09:16, Leo Bicknell  wrote:
> In a message written on Thu, Sep 23, 2010 at 04:26:05PM -0700, Owen DeLong wrote:
>> Subject: [arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55)
>
> [a line or two of text removed]
>
> I have no idea how this policy got to 55 revisions (I missed some
> of the middle discussion), that's not a good sign.

As a point of clarification; the policy text was built in
collaboration on a wiki and the revision number was updated with every
edit, however minor, as a result. I would say that we actually only
went through 3, maybe 4, true revisions and the rest was primarily
word-smithing.

~Chris

> --
> ? ? ? Leo Bicknell - bicknell at ufp.org - CCIE 3440
> ? ? ? ?PGP keys at http://www.ufp.org/~bicknell/
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>



-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org


From owen at delong.com  Wed Sep 29 11:46:51 2010
From: owen at delong.com (Owen DeLong)
Date: Wed, 29 Sep 2010 08:46:51 -0700
Subject: [arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55)
In-Reply-To: <20100929151655.GA1763@ussenterprise.ufp.org>
References: <28B1812C-FBCF-4EED-94CD-14FF2DBC4869@delong.com>
	<20100929151655.GA1763@ussenterprise.ufp.org>
Message-ID: <1AB25F51-BAD4-4DB5-8CE4-6A557A2FFE08@delong.com>

> 
> I think the community would be much better served by waiting.

Leo,

	Waiting is fatal if you want to set space aside for transition beyond
the /10 that is already set aside for a very vague and limited subset 
of transitional technologies. One of the key points of this was the
realization that with the broad set of transition needs staring us
in the face, 4.10 was wholly inadequate to the task and it really
does make much more sense to reserve the entire last /8.

	That can't wait until the next policy cycle. By then, it will be
allocated.

Owen




From bicknell at ufp.org  Wed Sep 29 11:56:03 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 29 Sep 2010 08:56:03 -0700
Subject: [arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55)
In-Reply-To: <1AB25F51-BAD4-4DB5-8CE4-6A557A2FFE08@delong.com>
References: <28B1812C-FBCF-4EED-94CD-14FF2DBC4869@delong.com>
	<20100929151655.GA1763@ussenterprise.ufp.org>
	<1AB25F51-BAD4-4DB5-8CE4-6A557A2FFE08@delong.com>
Message-ID: <20100929155603.GA7831@ussenterprise.ufp.org>

In a message written on Wed, Sep 29, 2010 at 08:46:51AM -0700, Owen DeLong wrote:
> 	Waiting is fatal if you want to set space aside for transition beyond
> the /10 that is already set aside for a very vague and limited subset 
> of transitional technologies. One of the key points of this was the
> realization that with the broad set of transition needs staring us
> in the face, 4.10 was wholly inadequate to the task and it really
> does make much more sense to reserve the entire last /8.

I don't have a strong position on the /8 vrs /10 argument.  I think
there are problems with both arguments, and in effect the community
is picking its favorite poison, rather than making anything better.
Would you prefer to die by firing squad or hanging?

That said, if folks really want to reserve a /8 I believe that can
be done in at least one, and perhaps two orders of magnitude less
text, in a way that is easy to understand and has no side effects.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: 

From jmaimon at chl.com  Wed Sep 29 12:01:08 2010
From: jmaimon at chl.com (Joe Maimon)
Date: Wed, 29 Sep 2010 12:01:08 -0400
Subject: [arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55)
In-Reply-To: <1AB25F51-BAD4-4DB5-8CE4-6A557A2FFE08@delong.com>
References: <28B1812C-FBCF-4EED-94CD-14FF2DBC4869@delong.com>	<20100929151655.GA1763@ussenterprise.ufp.org>
	<1AB25F51-BAD4-4DB5-8CE4-6A557A2FFE08@delong.com>
Message-ID: <4CA362C4.9090509@chl.com>



Owen DeLong wrote:
>>
>> I think the community would be much better served by waiting.
>
> Leo,
>
> 	Waiting is fatal if you want to set space aside for transition beyond
> the /10 that is already set aside for a very vague and limited subset
> of transitional technologies. One of the key points of this was the
> realization that with the broad set of transition needs staring us
> in the face, 4.10 was wholly inadequate to the task and it really
> does make much more sense to reserve the entire last /8.
>
> 	That can't wait until the next policy cycle. By then, it will be
> allocated.
>
> Owen
>

I agree with both Leo and Owen. That is what abandoned Policy Proposal 
#112 was all about, choosing to wait before deciding what do with the 
last /8 in minute detail.

http://lists.arin.net/pipermail/arin-ppml/2010-April/017410.html

Unless a policy will actively cause serious issues, even if all it 
accomplishes is preventing more of the last /8 from running through at 
the same rate as current, I am going to support it.

Joe


From marty at akamai.com  Wed Sep 29 18:50:09 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Wed, 29 Sep 2010 18:50:09 -0400
Subject: [arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55)
In-Reply-To: 
Message-ID: 




On 9/29/10 10:32 AM, "Chris Grundemann"  wrote:

> I think the fact that ARIN Staff is concerned that this policy may
> favor organizations who are granted reservations too much and Marty
> believes that it does not go far enough to provide relief to those
> same organizations illustrates that we have actually found a pretty
> decent compromise.

I don't think we are too far apart with respect to the concepts, it's the
mechanics and implementation that I have an issue with. In it's current form
I doubt that it is even implementable. Regardless,  the reservation
mechanisms are hugely unfair to large and small networks alike.

By reducing the allocation sizes only the larger reserved allocations are
significantly impacted. That impact is both planning and expense. The way
that the proposal reads to me is that if you make a reservation under a
class, you are assigned at min and could be max. If you are assigned the min
and the allocations are reduced based on inventory, you're good to go. If
you're reduced at the max, you're cut X% to insure that all reservations
over the lifecycle of the system are met. And everywhere in between.

//Examples

Assumptions: Normal member fees apply except when reservations reduced and
forced to the market aside from other requirements not addressed through
this proposal:

 Cost $1,000  /32  
 Need: /32
 Assignments=Assn1/2

             Assn1 Assn2 Addr Deficit Loss
 Funded         10 100   $0
 Reduce 10%     10  90   $10,000
 Reduce 20%     10  80   $20,000
 Reduce 30%     10  70   $30,000
 Reduce 40%     10  60   $40,000


If we didn't have the complexity issue, I'd support the proposal if we
implemented quarterly reductions which would be more fair. The quarterly
assignment would be based on demonstrated need:


Assumptions: Every address acquired through a transition proposal is a cost
savings to the network in a fair and equitable manner.

 Cost $1,000  /32  
 Need1: 10      Need2:  100
      
             QTRS   Need1       Need2
             12     120         1200
   Reduced 4 8      80          800
   Reduced 4 4      40          400
      
 Max Total Savings: $120,000  $1,200,000 All quarters
 Min Total Savings: $40,000   $400,000 All quarters

You might argue that the numbers are way disparate. Since the assignments
are need evaluated, the savings delta are not overly relevant. Unless we opt
to be communists[1].

If we are using a general ratio of one V6 /32 = v6 /64 with the quarterly
model we push out far more v6 that we would with the reductions as well.
Theoretical priming of the v6 pump: more is better even if shorter..


>An organization may request one reservation under each provision  listed in
>section 4.10.4. Once a reservation has been satisfied, another may be
>requested.

I'm not even accounting for the reservations in multiple classes.

Additional thoughts on leadership by such a proposal:

A. The minimum alloc is too low
B. We need to pick transition technologies, and not pick all of them
C. Make IPv4 unattractive
D. Support continued growth as much as possible during transition

1. COMMUNISM: You have two v4 /32 addresses. The state takes both and gives
you the dots.

Best,

-M<



From cgrundemann at gmail.com  Wed Sep 29 19:24:21 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Wed, 29 Sep 2010 17:24:21 -0600
Subject: [arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55)
In-Reply-To: 
References: 
	
Message-ID: 

On Wed, Sep 29, 2010 at 16:50, Hannigan, Martin  wrote:
>
>
>
> On 9/29/10 10:32 AM, "Chris Grundemann"  wrote:
>
>> I think the fact that ARIN Staff is concerned that this policy may
>> favor organizations who are granted reservations too much and Marty
>> believes that it does not go far enough to provide relief to those
>> same organizations illustrates that we have actually found a pretty
>> decent compromise.
>
> I don't think we are too far apart with respect to the concepts, it's the
> mechanics and implementation that I have an issue with. In it's current form
> I doubt that it is even implementable. Regardless, ?the reservation
> mechanisms are hugely unfair to large and small networks alike.
>
> By reducing the allocation sizes only the larger reserved allocations are
> significantly impacted. That impact is both planning and expense. The way
> that the proposal reads to me is that if you make a reservation under a
> class, you are assigned at min and could be max. If you are assigned the min
> and the allocations are reduced based on inventory, you're good to go. If
> you're reduced at the max, you're cut X% to insure that all reservations
> over the lifecycle of the system are met. And everywhere in between.
>


I think you misunderstand the mechanics. The actual effect of the
current text is VERY similar to your "quarterly reductions." I believe
the confusion lies between quarterly allocation sizes and reservation
sizes.

Let me try an example:

Org A requests the minimum quarterly allocation of a /25. That is one
/25 per quarter for 2 years which equals a /22 reservation.

Org B requests the maximum quarterly allocation of a /18. Adding up
two years worth of quarters gives them a /15 reservation.

The minimum reservation after reduction is one quarterly allocation at
the minimum; a /25.

The table looks like this (% is percent reduced, the ORg columns are
number of /32s reserved):

%	Org A	Org B
0	1024	131,072
25	768	98,304
50	512	65,536
75	256	32,768
87.5	128	16,384
93.75	128	8,192

What that says to me is that in the most extreme case (min vs max) the
reductions have to go over 87.5% before the small guy sees an
advantage. In all other cases, the percentage will be higher. In other
words, the larger reserved allocations are *not* the only ones
significantly affected by reductions.

Hope that helps,
~Chris

>
> Best,
>
> -M<
>
>



-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org


From owen at delong.com  Wed Sep 29 22:36:44 2010
From: owen at delong.com (Owen DeLong)
Date: Wed, 29 Sep 2010 19:36:44 -0700
Subject: [arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55)
In-Reply-To: <20100929155603.GA7831@ussenterprise.ufp.org>
References: <28B1812C-FBCF-4EED-94CD-14FF2DBC4869@delong.com>
	<20100929151655.GA1763@ussenterprise.ufp.org>
	<1AB25F51-BAD4-4DB5-8CE4-6A557A2FFE08@delong.com>
	<20100929155603.GA7831@ussenterprise.ufp.org>
Message-ID: 


On Sep 29, 2010, at 8:56 AM, Leo Bicknell wrote:

> In a message written on Wed, Sep 29, 2010 at 08:46:51AM -0700, Owen DeLong wrote:
>> 	Waiting is fatal if you want to set space aside for transition beyond
>> the /10 that is already set aside for a very vague and limited subset 
>> of transitional technologies. One of the key points of this was the
>> realization that with the broad set of transition needs staring us
>> in the face, 4.10 was wholly inadequate to the task and it really
>> does make much more sense to reserve the entire last /8.
> 
> I don't have a strong position on the /8 vrs /10 argument.  I think
> there are problems with both arguments, and in effect the community
> is picking its favorite poison, rather than making anything better.
> Would you prefer to die by firing squad or hanging?
> 
> That said, if folks really want to reserve a /8 I believe that can
> be done in at least one, and perhaps two orders of magnitude less
> text, in a way that is easy to understand and has no side effects.
> 
While I agree with you in principle, I will point out that in order to do so,
it has to happen in this policy cycle, or, through the emergency
process by the BoT.

The effort here was not only to reserve the /8, but, also define how it
should be used. I don't think you could fairly define that in less text
or in a way that is easier to understand. We tried very hard to do so.

Owen



From owen at delong.com  Wed Sep 29 23:32:58 2010
From: owen at delong.com (Owen DeLong)
Date: Wed, 29 Sep 2010 20:32:58 -0700
Subject: [arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55)
In-Reply-To: 
References: 
Message-ID: <45257890-94C5-4052-AF76-2E5B2BF6F61E@delong.com>


On Sep 29, 2010, at 3:50 PM, Hannigan, Martin wrote:

> 
> 
> 
> On 9/29/10 10:32 AM, "Chris Grundemann"  wrote:
> 
>> I think the fact that ARIN Staff is concerned that this policy may
>> favor organizations who are granted reservations too much and Marty
>> believes that it does not go far enough to provide relief to those
>> same organizations illustrates that we have actually found a pretty
>> decent compromise.
> 
> I don't think we are too far apart with respect to the concepts, it's the
> mechanics and implementation that I have an issue with. In it's current form
> I doubt that it is even implementable. Regardless,  the reservation
> mechanisms are hugely unfair to large and small networks alike.
> 
The alternative was to make it hugely unfair to small or large networks
in favor of the other. I would think that most people would call that
balance.

> By reducing the allocation sizes only the larger reserved allocations are
> significantly impacted. That impact is both planning and expense. The way
> that the proposal reads to me is that if you make a reservation under a
> class, you are assigned at min and could be max. If you are assigned the min
> and the allocations are reduced based on inventory, you're good to go. If
> you're reduced at the max, you're cut X% to insure that all reservations
> over the lifecycle of the system are met. And everywhere in between.
> 
That's simply not true. In order for the larger reserved allocations to be impacted
more than the smaller ones, the smaller ones already have to be down to a /28.
I don't think it makes sense to try and issue addresses from ARIN in any smaller
chunks.

Let's look at some semi-realistic examples.

A	An extra large organization qualifies for a reservation of a /18 per quarter
B	A large organization qualifies for a reservation of a /20 per quarter
C	A medium organization comes out to a /22
D	A small organization works out to a /24
and
E	an X-small organization works out to a /28

Multiplying each by 8 quarters (24 months)
A	is a /15
B	is a /17
C	is a /19
D	is a /21
and
E	is a /25

Let's assume that the combined reservations in the other categories add up
such that this category is limited to a /16 total space available.
(This isn't a realistic limit under the proposed policy, but, a realistic limit
would require me to generate a much larger set of requestors to over-
subscribe the space.)

Obviously we can't fulfill all of the reservations from a /16, so, we
take one bit away from each reservation...

A	is now a /16
B	is now a /18
C	is now a /20
D	is now a /22
and
E	is now a /26

This still oversubscribes the space, so, we hack off one more bit...

A	is now a /17
B	is now a /19
C	is now a /21
D	is now a /23
and
E	is now a /27

Everyone gets 1/4 of what they applied for and they all go away similarly
unhappy.

Now, let's say that instead of a /16, we had only a /18 left for this category.
Again, even more unrealistic to the policy, but, illustrative, nonetheless...

A	would get reduced to a /19
B	would get reduced to a /21
C	would get reduced to a /23
D	would get reduced to a /25
and
E	would get reduced to a /28

Everyone gets 1/16th of what they qualified for, except E who gets 1/8 of what
he qualified for. Is this favoring E over all the others? Well, arguably, yes, but,
would the others gain anything at all if we gave E a /29 instead of the /28?
Actually... No... There wouldn't be enough there to give meaningful additional
space to any of the larger requestors anyway. You'd need at least 8 E-sized
organizations reduced to zero in order to even give D another /25.

> //Examples
> 
> Assumptions: Normal member fees apply except when reservations reduced and
> forced to the market aside from other requirements not addressed through
> this proposal:
> 
> Cost $1,000  /32  
> Need: /32
> Assignments=Assn1/2
> 
>             Assn1 Assn2 Addr Deficit Loss
> Funded         10 100   $0
> Reduce 10%     10  90   $10,000
> Reduce 20%     10  80   $20,000
> Reduce 30%     10  70   $30,000
> Reduce 40%     10  60   $40,000
> 
I'm not sure I understand your table here, so, I won't comment.

> 
> If we didn't have the complexity issue, I'd support the proposal if we
> implemented quarterly reductions which would be more fair. The quarterly
> assignment would be based on demonstrated need:
> 
I would not be opposed to removing one quarter at a time rather than one
bit, but, I think numerically you arrive at roughly the same result.

> 
> Assumptions: Every address acquired through a transition proposal is a cost
> savings to the network in a fair and equitable manner.
> 
> Cost $1,000  /32  
> Need1: 10      Need2:  100
> 
>             QTRS   Need1       Need2
>             12     120         1200
>   Reduced 4 8      80          800
>   Reduced 4 4      40          400
> 
> Max Total Savings: $120,000  $1,200,000 All quarters
> Min Total Savings: $40,000   $400,000 All quarters
> 
> You might argue that the numbers are way disparate. Since the assignments
> are need evaluated, the savings delta are not overly relevant. Unless we opt
> to be communists[1].
> 
> If we are using a general ratio of one V6 /32 = v6 /64 with the quarterly
> model we push out far more v6 that we would with the reductions as well.
> Theoretical priming of the v6 pump: more is better even if shorter..
> 
I suspect you mean one V4 /32 = one V6 /64, but, I hesitate to comment
on speculative interpretations of your intent.

I do think your estimate of $1,000 per /32 is speculative at best.

> 
>> An organization may request one reservation under each provision  listed in
>> section 4.10.4. Once a reservation has been satisfied, another may be
>> requested.
> 
> I'm not even accounting for the reservations in multiple classes.
> 
> Additional thoughts on leadership by such a proposal:
> 
> A. The minimum alloc is too low

Raising the minimum allocation reduces the fairness to larger organizations
while simultaneously locking out a progressively larger number of smaller
organizations. As such, I felt it was best to bring it back to smaller numbers.

> B. We need to pick transition technologies, and not pick all of them

In general any effort at having ARIN pick technologies has been rebuffed by
the community. I'm not sure why you think this policy could somehow be an
exception.

> C. Make IPv4 unattractive

It already is and the costs of IPv4 depletion will make it more unattractive.

The problem isn't that IPv4 is attractive. The problem is that IPv6 isn't
attractive enough to get most people over the hump. I believe that
is a self-resolving problem, but, the problem is that many organizations
are not prepared for the transition and will, as a result, suffer a greater
level of pain than they would if they had prepared earlier.

> D. Support continued growth as much as possible during transition

This proposal seeks to do just that. However, the end reality is that there
are only 16.7 million addresses in the last /8. The only way to maximize
growth during transition is to leverage those addresses to as many
IPv6 hosts supported as possible. Realistically, that's why there is
such strong language protecting 4.10.4(c) (the remaining remnant of
the original 2010-13) in the policy. It provides the maximum leverage
of users served vs. addresses issued of any of the use cases in the
policy.

> 
> 1. COMMUNISM: You have two v4 /32 addresses. The state takes both and gives
> you the dots.
> 
It's not communism to believe that you should not give all of the
remaining space to the first person in line. I don't think anyone would
call Ticketron/Bass/etc. communists, but, even they do not allow
someone to walk up and purchase all of the tickets for a concert
that is expected to sell rapidly. Being first in line should not put
you at an overwhelming advantage over those behind you.

Owen


-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From marty at akamai.com  Thu Sep 30 08:18:07 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Thu, 30 Sep 2010 08:18:07 -0400
Subject: [arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55)
In-Reply-To: <45257890-94C5-4052-AF76-2E5B2BF6F61E@delong.com>
Message-ID: 




On 9/29/10 11:32 PM, "Owen DeLong"  wrote:

> 
> On Sep 29, 2010, at 3:50 PM, Hannigan, Martin wrote:
> 
>> 
>> 
>> 
[ snip ]

>> By reducing the allocation sizes only the larger reserved allocations are
>> significantly impacted. That impact is both planning and expense. The way
>> that the proposal reads to me is that if you make a reservation under a
>> class, you are assigned at min and could be max. If you are assigned the min
>> and the allocations are reduced based on inventory, you're good to go. If
>> you're reduced at the max, you're cut X% to insure that all reservations
>> over the lifecycle of the system are met. And everywhere in between.
>> 
> That's simply not true. In order for the larger reserved allocations to be
> impacted
> more than the smaller ones, the smaller ones already have to be down to a /28.
> I don't think it makes sense to try and issue addresses from ARIN in any
> smaller
> chunks.
> 

I don't believe that we're saying anything different with respect to
inequities. Look at it from this perspective; if you have 1M /28
reservations and you have 1 x /18 reservation, in order to fulfill all or
most of the /28's you'll eat away at the /18.



[ slip ]

>> //Examples
>> 
>> Assumptions: Normal member fees apply except when reservations reduced and
>> forced to the market aside from other requirements not addressed through
>> this proposal:
>> 
>>  Cost $1,000  /32
>>  Need: /32
>>  Assignments=Assn1/2
>> 
>>              Assn1 Assn2 Addr Deficit Loss
>>  Funded         10 100   $0
>>  Reduce 10%     10  90   $10,000
>>  Reduce 20%     10  80   $20,000
>>  Reduce 30%     10  70   $30,000
>>  Reduce 40%     10  60   $40,000
>> 
> I'm not sure I understand your table here, so, I won't comment.

Assume that the "multiple" /28 holders are Assn1 and the rest is Ass2. As
you drain the pool to fund the allocations of the smaller assignments you
ended up pushing the cost of replacing those addresses onto the others in
the pool.

>> If we didn't have the complexity issue, I'd support the proposal if we
>> implemented quarterly reductions which would be more fair. The quarterly
>> assignment would be based on demonstrated need:
>> 
> I would not be opposed to removing one quarter at a time rather than one
> bit, but, I think numerically you arrive at roughly the same result.
> 
>> 
>> Assumptions: Every address acquired through a transition proposal is a cost
>> savings to the network in a fair and equitable manner.
>> 
>>  Cost $1,000  /32
>>  Need1: 10      Need2:  100
>> 
>>              QTRS   Need1       Need2
>>              12     120         1200
>>    Reduced 4 8      80          800
>>    Reduced 4 4      40          400
>> 
>>  Max Total Savings: $120,000  $1,200,000 All quarters
>>  Min Total Savings: $40,000   $400,000 All quarters
>> 
>> You might argue that the numbers are way disparate. Since the assignments
>> are need evaluated, the savings delta are not overly relevant. Unless we opt
>> to be communists[1].
>> 
>> If we are using a general ratio of one V6 /32 = v6 /64 with the quarterly
>> model we push out far more v6 that we would with the reductions as well.
>> Theoretical priming of the v6 pump: more is better even if shorter..
>> 
> I suspect you mean one V4 /32 = one V6 /64, but, I hesitate to comment
> on speculative interpretations of your intent.

No, that's correct. V4 /32.


> 
> I do think your estimate of $1,000 per /32 is speculative at best.

What do you think that this cost is currently?


[ snip ]

> 
>> 
>> 1. COMMUNISM: You have two v4 /32 addresses. The state takes both and gives
>> you the dots.
>> 
> It's not communism to believe that you should not give all of the
> remaining space to the first person in line. I don't think anyone would
> call Ticketron/Bass/etc. communists, but, even they do not allow
> someone to walk up and purchase all of the tickets for a concert
> that is expected to sell rapidly. Being first in line should not put
> you at an overwhelming advantage over those behind you.


Not sure what the relevance of the follow-up is. No one is advocating that
anyone be able to land grab. Any policy that allows that is deficient. I'm
advocating that we abandon this proposal again.

Best,

-M<




From owen at delong.com  Thu Sep 30 09:44:33 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 30 Sep 2010 06:44:33 -0700
Subject: [arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55)
In-Reply-To: 
References: 
Message-ID: 

> 
> I don't believe that we're saying anything different with respect to
> inequities. Look at it from this perspective; if you have 1M /28
> reservations and you have 1 x /18 reservation, in order to fulfill all or
> most of the /28's you'll eat away at the /18.
> 
And if you have 1,000 /25s and 1 /18 you'll eat away at the /25s in order
to give something to the /18 guy. Correct. Not giving the entire available
space to the first guy in line just because he got there a couple of hours
ahead isn't my idea of unfair.

> 
> 
> [ slip ]
> 
>>> //Examples
>>> 
>>> Assumptions: Normal member fees apply except when reservations reduced and
>>> forced to the market aside from other requirements not addressed through
>>> this proposal:
>>> 
>>> Cost $1,000  /32
>>> Need: /32
>>> Assignments=Assn1/2
>>> 
>>>             Assn1 Assn2 Addr Deficit Loss
>>> Funded         10 100   $0
>>> Reduce 10%     10  90   $10,000
>>> Reduce 20%     10  80   $20,000
>>> Reduce 30%     10  70   $30,000
>>> Reduce 40%     10  60   $40,000
>>> 
>> I'm not sure I understand your table here, so, I won't comment.
> 
> Assume that the "multiple" /28 holders are Assn1 and the rest is Ass2. As
> you drain the pool to fund the allocations of the smaller assignments you
> ended up pushing the cost of replacing those addresses onto the others in
> the pool.
> 
The same is true in reverse.

>>> If we didn't have the complexity issue, I'd support the proposal if we
>>> implemented quarterly reductions which would be more fair. The quarterly
>>> assignment would be based on demonstrated need:
>>> 
>> I would not be opposed to removing one quarter at a time rather than one
>> bit, but, I think numerically you arrive at roughly the same result.
>> 
>>> 
>>> Assumptions: Every address acquired through a transition proposal is a cost
>>> savings to the network in a fair and equitable manner.
>>> 
>>> Cost $1,000  /32
>>> Need1: 10      Need2:  100
>>> 
>>>             QTRS   Need1       Need2
>>>             12     120         1200
>>>   Reduced 4 8      80          800
>>>   Reduced 4 4      40          400
>>> 
>>> Max Total Savings: $120,000  $1,200,000 All quarters
>>> Min Total Savings: $40,000   $400,000 All quarters
>>> 
>>> You might argue that the numbers are way disparate. Since the assignments
>>> are need evaluated, the savings delta are not overly relevant. Unless we opt
>>> to be communists[1].
>>> 
>>> If we are using a general ratio of one V6 /32 = v6 /64 with the quarterly
>>> model we push out far more v6 that we would with the reductions as well.
>>> Theoretical priming of the v6 pump: more is better even if shorter..
>>> 
>> I suspect you mean one V4 /32 = one V6 /64, but, I hesitate to comment
>> on speculative interpretations of your intent.
> 
> No, that's correct. V4 /32.
> 
> 
>> 
>> I do think your estimate of $1,000 per /32 is speculative at best.
> 
> What do you think that this cost is currently?
> 
Since I don't have any legitimate address trading data to back it up, and,
since to the best of my knowledge, no-one has exercised 8.3 as yet,
neither do you, I would argue that any number would be speculative
at best.

> 
> [ snip ]
> 
>> 
>>> 
>>> 1. COMMUNISM: You have two v4 /32 addresses. The state takes both and gives
>>> you the dots.
>>> 
>> It's not communism to believe that you should not give all of the
>> remaining space to the first person in line. I don't think anyone would
>> call Ticketron/Bass/etc. communists, but, even they do not allow
>> someone to walk up and purchase all of the tickets for a concert
>> that is expected to sell rapidly. Being first in line should not put
>> you at an overwhelming advantage over those behind you.
> 
> 
> Not sure what the relevance of the follow-up is. No one is advocating that
> anyone be able to land grab. Any policy that allows that is deficient. I'm
> advocating that we abandon this proposal again.
> 
But you're opposing this proposal specifically because it doesn't
allow for the land grab.

Owen



From marty at akamai.com  Thu Sep 30 09:59:02 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Thu, 30 Sep 2010 09:59:02 -0400
Subject: [arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55)
In-Reply-To: 
Message-ID: 




On 9/30/10 9:44 AM, "Owen DeLong"  wrote:

>> 
>> I don't believe that we're saying anything different with respect to
>> inequities. Look at it from this perspective; if you have 1M /28
>> reservations and you have 1 x /18 reservation, in order to fulfill all or
>> most of the /28's you'll eat away at the /18.
>> 
> And if you have 1,000 /25s and 1 /18 you'll eat away at the /25s in order
> to give something to the /18 guy. Correct. Not giving the entire available
> space to the first guy in line just because he got there a couple of hours
> ahead isn't my idea of unfair.


Ah, no. The theoretical /25's and /18's would have been approved based on
need. An equal reduction for all bolsters the equity of needs based
allocations. Capping the reduction on the low side is the Robin Hood
approach. 


Best,

-M<




From owen at delong.com  Thu Sep 30 10:12:00 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 30 Sep 2010 07:12:00 -0700
Subject: [arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55)
In-Reply-To: 
References: 
Message-ID: <502A0F78-0A9E-444F-A256-6C4445AA60C0@delong.com>


On Sep 30, 2010, at 6:59 AM, Hannigan, Martin wrote:

> 
> 
> 
> On 9/30/10 9:44 AM, "Owen DeLong"  wrote:
> 
>>> 
>>> I don't believe that we're saying anything different with respect to
>>> inequities. Look at it from this perspective; if you have 1M /28
>>> reservations and you have 1 x /18 reservation, in order to fulfill all or
>>> most of the /28's you'll eat away at the /18.
>>> 
>> And if you have 1,000 /25s and 1 /18 you'll eat away at the /25s in order
>> to give something to the /18 guy. Correct. Not giving the entire available
>> space to the first guy in line just because he got there a couple of hours
>> ahead isn't my idea of unfair.
> 
> 
> Ah, no. The theoretical /25's and /18's would have been approved based on
> need. An equal reduction for all bolsters the equity of needs based
> allocations. Capping the reduction on the low side is the Robin Hood
> approach. 
> 
Look, at some low side point, one has to cap the reduction. If nothing else,
it absolutely impossible to hand out a fractional /32.

I think it is impractical to hand out less than a /28.

I'll point out that you were the one in our earlier discussions who wanted to
raise this threshold rather than lower it.

Owen



From rudi.daniel at gmail.com  Thu Sep 30 12:53:28 2010
From: rudi.daniel at gmail.com (Rudolph Daniel)
Date: Thu, 30 Sep 2010 12:53:28 -0400
Subject: [arin-ppml] ARIN-PPML Digest, Vol 63, Issue 32
In-Reply-To: <17ECD436-9BD6-4F87-B445-3BEF24D91A58@delong.com>
References: 
	
	<17ECD436-9BD6-4F87-B445-3BEF24D91A58@delong.com>
Message-ID: 

I have to admit that my choice of "policy strategy when it comes to IPv6
adoption" is to go with 4.10 as is.

Rudi Daniel



On Wed, Sep 29, 2010 at 11:36 AM, Owen DeLong  wrote:

> Rudy,
> The reason for the detailed criteria is to preserve these specific
> final addresses in support of IPv6 transition rather than further
> consumption
> under the business as usual rules.
>
> The alternative, of course, is to leave policy as it is, consuming
> the few remaining IPv4 addresses under the current system with
> virtually nothing set aside to facilitate transition to IPv6 other than
> a very limited subset of technologies specified in the existing 4.10.
>
> Owen
>
> On Sep 29, 2010, at 7:49 AM, Rudolph Daniel wrote:
>
> I cannot support 2010-13 presently because it still seems to me to be
> overtly complex prone to misunderstanding.
>
> One example: >ISPs can apply for /32s for customers as long as each
> customer
> > meets the policy's detailed qualification criteria. As an ISP, I may not
> be too happy imposing detailed qualification criteria which will be a beyond
> my commercial requirement and may simply frustrate and complicate the
> process at all levels.
>
> Rudi Daniel
>
>
>
> On Wed, Sep 29, 2010 at 10:33 AM,  wrote:
>
>> Send ARIN-PPML mailing list submissions to
>>        arin-ppml at arin.net
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>        http://lists.arin.net/mailman/listinfo/arin-ppml
>> or, via email, send a message with subject or body 'help' to
>>        arin-ppml-request at arin.net
>>
>> You can reach the person managing the list at
>>        arin-ppml-owner at arin.net
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of ARIN-PPML digest..."
>>
>>
>> Today's Topics:
>>
>>   1. Re: Final draft of 2010-13 for Atlanta (Rev 1.55)
>>      (Hannigan, Martin)
>>   2. Re: Final draft of 2010-13 for Atlanta (Rev 1.55)
>>      (Chris Grundemann)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Tue, 28 Sep 2010 17:55:37 -0400
>> From: "Hannigan, Martin" 
>> To: "arin-ppml at arin.net" 
>> Subject: Re: [arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55)
>> Message-ID: 
>> >
>> Content-Type: text/plain; charset="Windows-1252"
>>
>>
>>
>> I oppose this proposal. I think it's destructive; it's complicated and
>> fails
>> to establish any leadership and it's divisive; the reservation system and
>> classes of requests create significant inequities for all that have need.
>> It
>> fails to allow anyone to plan. The end result is that we're going to pit
>> all
>> of our members against each other in open markets. Regardless of this
>> proposal, that may happen still. When I supported the petition I had hoped
>> that we could stretch this remaining space and provide some relief and
>> define what's important with regards to continuing to grow the net while
>> we
>> transition. That is impossible with this proposal and perhaps impossible
>> with any proposal and a single /8[1]. [ The recent CableLabs Draft is very
>> interesting FWIW]
>>
>> This proposal still does not go far enough in offering some level of
>> relief
>> to all segments of the industry. I concur with the staff comments related
>> and specifically comments related to the complexity.
>>
>> I did support "the concept" of the reservation system with different terms
>> and provider relief with respect to CPE et. Al. The proposal fails to
>> explain itself adequately with respect to both and if it were adequately
>> explained it may seem less unfair if it were re-written. Transition not be
>> without pain and some of us are already challenged by it.
>>
>> I don't have a suggestion other than a complete rewrite which is why I
>> support completely abandoning it.
>>
>>
>> Best,
>>
>> -M<
>>
>>
>>
>> 1. http://tools.ietf.org/html/draft-weil-opsawg-provider-address-space-00
>>
>>
>>
>>
>>
>>
>> On 9/27/10 4:02 PM, "ARIN"  wrote:
>>
>> > Draft Policy 2010-13
>> > Permitted Uses of space reserved under NRPM 4.10
>> >
>> > Attached is the ARIN staff assessment of 2010-13. We assessed the 1.53
>> > version of the draft policy (it's currently at 1.55). It is noted that
>> > the time frame for reserves has been reduced from 36 to 24 months in
>> > version 1.55.
>> >
>> > This draft policy is open for discussion on this mailing list and will
>> > be on the agenda at the upcoming ARIN Public Policy Meeting in Atlanta.
>> >
>> > 2010-13 is below and available at:
>> > https://www.arin.net/policy/proposals/2010_13.html
>> >
>> > Regards,
>> >
>> > Communications and Member Services
>> > American Registry for Internet Numbers (ARIN)
>> >
>> >
>> > ## * ##
>> >
>> >
>> > Staff Assessment of Draft Policy 2010-13 (version 1.53 dated 19
>> > September 2010)
>> >
>> > Permitted Uses of space reserved under NRPM 4.10
>> >
>> > 1. Proposal Summary (Staff Understanding)
>> >
>> > This policy modifies the existing NRPM policy 4.10 (?Dedicated IPv4
>> > block to facilitate IPv6 Deployment?).  It sets aside in its entirety
>> > the last /8 ARIN receives from the IANA for issuance to networks
>> > transitioning to a dual IPv4/IPv6 network rather than the /10 currently
>> > cited in NRPM 4.10. Any IPv4 address space returned to ARIN (and not
>> > subject to a global or regional transfer policy) will be added to this
>> > transition pool.  Under this policy there are four major classes of
>> > requestors:
>> >
>> >    - ISPs can apply for /32s for customers as long as each customer
>> > meets the policy's detailed qualification criteria.
>> >
>> >    - Any operator can apply for /32s for issuing to devices used to
>> > serve-up internet facing content, within the constraints of the defined
>> > qualifying criteria.
>> >
>> >    - From the /8, a /10 will be set aside so that any operator can
>> > request space for use in infrastructure numbering for the purposes of
>> > deploying IPv6. Space can be issued from this /8 for applicants who
>> > qualify under ARIN's Micro-allocation Policy (with additional
>> > restrictions).
>> >
>> >    - Finally, space can be issued from this /8 for applicants who
>> > operate content distribution networks, again, within the context of the
>> > policy's qualifying criteria.
>> >
>> > Organizations can request address space to meet their 3-year needs.
>> > Space is allocated/assigned in quarterly installments.  After the first
>> > quarter, the requestor can only return to ARIN if they have utilized 80%
>> > of the most recent assignment, and 90% of past assignments (issued under
>> > this policy). The organization must have also assigned all IP addresses
>> > issued under the policy to uses that are acceptable under the policy.
>> > If the organization fails to meet the utilization criteria for four
>> > consecutive quarters, then the policy directs ARIN staff to reduce the
>> > amount of space reserved.
>> >
>> > 2. Comments
>> >
>> >   A.    ARIN Staff Comments
>> >
>> >    ? The policy text has become very complex and complicated and the
>> > general community will have a very hard time understanding the concepts
>> > and criteria proposed within the policy.
>> >
>> >    ? It seems to be out of order ? it starts out with reservations
>> > before ever mentioning the initial qualifying criteria.  The author
>> > might want to consider re-ordering to start with the essential
>> > qualification criteria first.
>> >
>> >    ? Section 4.10.2 suggests that all allocations made under this policy
>> > will initially be made from a 3-year reservation.  In light of the
>> > imminent depletion of IPv4 address space, it doesn't seem fair to allow
>> > some organizations to retain/reserve this valuable resource for up to 3
>> > years while others will be denied.
>> >
>> >    ? The policy text in (in 4.10.3) appears to contradict itself, as it
>> > first directs staff to remove one quarter's worth of reservation, and
>> > then, if the organization continues this practice for three consecutive
>> > quarters, remove the organization's reserves completely. Later, it
>> > explicitly directs staff to revoke addresses issued under this policy
>> > that are used by the organizations for purposes not permitted under this
>> > policy.
>> >
>> >    ? This proposal will essentially supplant the recently ratified
>> > policy "Waiting List for Unmet Resources". That list will consist of
>> > people waiting for resources to be returned or revoked so that ARIN can
>> > then reissue them to requestors in need of IPv4 address space.  This
>> > proposal says that any IPv4 address space that comes back to ARIN
>> > immediately goes into the IPv6 transition pool and can only be used for
>> > that purpose.
>> >
>> >    ? Under 4.10.4.B5, how would staff be able to verify that x percent
>> > of an organization?s content is IPv6 reachable?
>> >
>> >
>> >   B. ARIN General Counsel
>> > This policy is unlikely to cause any legal issues of any importance.
>> >
>> >
>> > 3. Resource Impact
>> >
>> > This policy would have moderate to major resource impact.  It is
>> > estimated that implementation would occur within 6 to 9 months after
>> > ratification by the ARIN Board of Trustees. The following would be
>> > needed in order to implement:
>> >    ? Changes to the way ARIN manages reverse DNS (to handle in-addr.arpa
>> > delegations for blocks smaller than /24)
>> >    ? Updated guidelines
>> >    ? Staff training
>> >
>> >
>> >> -----Original Message-----
>> >
>> >> From: Owen DeLong [mailto:owen at delong.com]
>> >
>> >> Sent: Thursday, September 23, 2010 7:26 PM
>> >
>> >> To: arin-ppml at arin.net List; policy
>> >
>> >> Subject: Final draft of 2010-13 for Atlanta (Rev 1.55)
>> >
>> >>
>> >
>> >> Changes:
>> >
>> >>
>> >
>> >> 1. Set maximum reservation period to 24 months. This avoids creating
>> >
>> >> a 4-year reservation by CIDR-rounding 36 month reservations.
>> >
>> >> 2. Reduced minimum size for 4.10.4(b) to /28
>> >
>> >>
>> >
>> >> These changes will make the policy more balanced and reduce the extent
>> >
>> >> to
>> >
>> >> which larger organizations could be disadvantaged relative to smaller
>> >
>> >> smaller organizations if reservations have to be resized.
>> >
>> >>
>> >
>> >> The change to a 2-year system resolves an issue with the CIDR-Rounding
>> >
>> >> where a 36-month reservation is mathematically guaranteed to become a
>> >
>> >> 48-month reservation. The other alternative was to round-down instead
>> >
>> >> of
>> >
>> >> up which would have mathematically converted all reservations to 2
>> >
>> >> years.
>> >
>> >> As such, a 2-year reservation system seemed the cleanest and most
>> >
>> >> straightforward approach.
>> >
>> >>
>> >
>> >> Owen
>> >
>> >>
>> >
>> >> Draft Policy 2010-13: Permitted Uses of Space Reserved under NRPM 4.10
>> >
>> >> Proposal Originator: Owen DeLong, Chris Grundemann
>> >
>> >> Proposal Version: 1.55
>> >
>> >> Date: 23 September 2010
>> >
>> >> Proposal type: modify
>> >
>> >> Policy term: permanent
>> >
>> >> Policy statement:
>> >
>> >>
>> >
>> >> Remove section 4.1.8 (Unmet requests) from the NRPM.
>> >
>> >> Replace the text of section 4.10 in its entirety (including the name)
>> >
>> >> with:
>> >
>> >>
>> >
>> >> 4.10 IPv4 Transition Pool Post IANA Regular Pool Depletion
>> >
>> >>
>> >
>> >> When ARIN receives its /8 IPv4 allocation from IANA under the
>> >
>> >> global policy titled "Global Policy for the Allocation of the
>> >
>> >> Remaining IPv4 Address Space" ratified by ICANN Board
>> >
>> >> on 6 March, 2009, that /8 will form a dedicated pool to
>> >
>> >> facilitate IPv6 Deployment.
>> >
>> >>
>> >
>> >> Addresses returned to ARIN and not subject to a regional or
>> >
>> >> global transfer policy will be reserved for utilization in the
>> >
>> >> transition
>> >
>> >> pool.
>> >
>> >>
>> >
>> >> Allocations and assignments from this block must be justified by
>> >
>> >> IPv6 transition requirements.
>> >
>> >>
>> >
>> >> ARIN will use their discretion in determining whether a
>> >
>> >> particular
>> >
>> >> application meets the spirit of this policy.
>> >
>> >>
>> >
>> >> 4.10.1 Addressing Plan
>> >
>> >>
>> >
>> >> Any organization wishing to receive IPv4 addresses through this
>> >
>> >> policy must submit a detailed addressing plan for any request
>> >
>> >> that is made containing the following:
>> >
>> >> (a) Their addressing needs over the entire reservation period
>> >
>> >> and
>> >
>> >> (b) Methods of meeting all requirements (requirements are
>> >
>> >> explained in section 4.10.4.) over the entire reservation
>> >
>> >> period.
>> >
>> >>
>> >
>> >> 4.10.2 Reservation System
>> >
>> >>
>> >
>> >> Initially, all space assigned or allocated under this policy will
>> >
>> >> be
>> >
>> >> reserved in advance for a maximum period of 24 months, requests
>> >
>> >> for
>> >
>> >> shorter reservations will be accepted. The total reservation size
>> >
>> >> will be rounded up to a CIDR bit boundary.
>> >
>> >>
>> >
>> >> Each organization's reservation amount will be divided
>> >
>> >> into quarterly allotments. Allotments will be rounded up
>> >
>> >> to a CIDR bit boundary. The final quarterly allotment will
>> >
>> >> contain only the remaining space from the full reservation.
>> >
>> >>
>> >
>> >> An organization may request one reservation under each provision
>> >
>> >> listed in section 4.10.4. Once a reservation has been satisfied,
>> >
>> >> another may be requested.
>> >
>> >>
>> >
>> >> 4.10.2.1 Reservation Requests Prior to Initial ARIN Free Pool
>> >
>> >> Depletion
>> >
>> >>
>> >
>> >> Reservations will be accepted from the time that this policy
>> >
>> >> is adopted until the day that ARIN can no longer fill regular
>> >
>> >> requests from
>> >
>> >> space allocated to ARIN by IANA. At that time, if necessary, all
>> >
>> >> reservations
>> >
>> >> will be reduced by an equal amount to allow them to fit within
>> >
>> >> the total space available in the transition pool. No reservation
>> >
>> >> will be reduced lower than the minimum quarterly allotment for
>> >
>> >> it's category. Each organization may decide whether to adjust
>> >
>> >> the reservation period or the allotment size (within the stated
>> >
>> >> range) when reservations are reduced. Organizations must make
>> >
>> >> this decision within 30 days of announcement and may not alter
>> >
>> >> their choice once made. Any space added to the transition
>> >
>> >> pool during this time will cause a final recalculation of
>> >
>> >> reservation sizes. Once all necessary adjustments are
>> >
>> >> made, all reservations are guaranteed and the first quarterly
>> >
>> >> allotment is issued to each org.
>> >
>> >>
>> >
>> >> 4.10.2.2 Reservation Requests Post ARIN Free Pool Depletion
>> >
>> >>
>> >
>> >> Reservation requests received after ARIN free pool depletion
>> >
>> >> as defined in 4.10.2.1 will not be guaranteed. If approved, such
>> >
>> >> requests will be placed in a queue. As space becomes available in
>> >
>> >> the transition pool it will be used to provide allotments to
>> >
>> >> organizations with reservations in the queue on a first-approved
>> >
>> >> first-served basis. Partially filled allotments will remain at
>> >
>> >> the
>> >
>> >> front of the queue.
>> >
>> >>
>> >
>> >> 4.10.2.3 Abandonment of Reservation
>> >
>> >>
>> >
>> >> Any organization may abandon their remaining reservation at any
>> >
>> >> time by informing ARIN of their desire to do so. Upon
>> >
>> >> abandonment,
>> >
>> >> the remaining space in the reservation will be returned to the
>> >
>> >> transition pool.
>> >
>> >>
>> >
>> >> 4.10.3 Quarterly Requirements
>> >
>> >>
>> >
>> >> Organizations with approved reservations and address plans
>> >
>> >> are entitled to quarterly allotments. In order to receive each
>> >
>> >> additional allotment, an organization must submit evidence of
>> >
>> >> compliance with the following sub-sections:
>> >
>> >> (a) The most recent 4.10 allotment is at least 80% utilized.
>> >
>> >> (b) All prior 4.10 allotments within the same 4.10.4
>> >
>> >> category are at least 90% utilized.
>> >
>> >> (c) All utilization is permitted under the 4.10.4 category for
>> >
>> >> which it was initially requested.
>> >
>> >>
>> >
>> >> For purposes of this computation, space received under each
>> >
>> >> provision shall be considered separately if an organization has
>> >
>> >> received resources through multiple provisions.
>> >
>> >>
>> >
>> >> If an organization does not meet all obligations in any given
>> >
>> >> quarter, that organization shall not receive that quarter's
>> >
>> >> allotment
>> >
>> >> and shall have their reservation reduced by one quarterly
>> >
>> >> allotment.
>> >
>> >> If an organization does not meet all obligations
>> >
>> >> for three consecutive quarters, that organization forfeits the
>> >
>> >> remainder
>> >
>> >> of their reserved block.
>> >
>> >>
>> >
>> >> Utilization requirements (a) may be delayed at ARIN's discretion.
>> >
>> >>
>> >
>> >> If an organization is using space received under 4.10 in a manner
>> >
>> >> contrary to 4.10, that organization forfeits their remaining
>> >
>> >> reservation and may have their entire allocation or assignment
>> >
>> >> revoked.
>> >
>> >>
>> >
>> >> All 4.10. space forfeited, revoked or otherwise reclaimed shall
>> >
>> >> be returned to the ARIN transition pool.
>> >
>> >>
>> >
>> >> 4.10.4 Specific types of transitional uses have specific
>> >
>> >> requirements:
>> >
>> >>
>> >
>> >> (a) An ISP/LIR may request a block no smaller than a /25 nor
>> >
>> >> larger than a /18 per quarter to be used to provide single
>> >
>> >> IPv4 /32s to their customers which could justify a /28 or
>> >
>> >> more of IPv4 under ARIN policies in effect at the time of
>> >
>> >> IANA depletion.
>> >
>> >> 1. No customer site may receive more than a single
>> >
>> >> IPv4 /32 per 1,000 Internet connected hosts upto 8
>> >
>> >> /32s.
>> >
>> >> 2. The customer site must not have any IPv4
>> >
>> >> addresses not issued under this policy.
>> >
>> >> 3. The customer site must use the /32 to provide
>> >
>> >> IPv4 connectivity for hosts which have IPv6
>> >
>> >> addresses with IPv6 connectivity to the ISP/LIR.
>> >
>> >> 4. The ISP/LIR must demonstrate that it already
>> >
>> >> provides IPv6 addressing and connectivity to at
>> >
>> >> least one additional existing customer site for
>> >
>> >> each /32 requested, up to 90% of all customer sites
>> >
>> >> served (across all customers).
>> >
>> >> 5. An ISP/LIR customer which is not large enough to
>> >
>> >> qualify
>> >
>> >> under this provision and has no unassigned IPv4
>> >
>> >> addresses
>> >
>> >> may receive an appropriate number of /32s from their
>> >
>> >> upstream provider for reassignment to their customers
>> >
>> >> under the terms of 4.10.4(a).
>> >
>> >> 6. A customer site which terminates multiple connections
>> >
>> >> from the same provider on separate routers may
>> >
>> >> qualify
>> >
>> >> for one /32 per unique router with a direct
>> >
>> >> connection to
>> >
>> >> the provider, up to a total of 8 /32s.
>> >
>> >> 7. The total space issued to all organizations under
>> >
>> >> this provision shall not exceed an aggregate /9
>> >
>> >> or equivalent per /8 placed into the transition pool.
>> >
>> >>
>> >
>> >>
>> >
>> >> (b) An ISP/LIR or End user organization may request a block
>> >
>> >> no smaller than a /28 and no larger than a /18 per quarter
>> >
>> >> to provide single IPv4 /32s to each physical server used
>> >
>> >> to provide Internet reachable content.
>> >
>> >> 1. Space issued under this provision is an assignment,
>> >
>> >> not an allocation. An LIR may not distribute this
>> >
>> >> space to their customers.
>> >
>> >> 2. No server may receive more than a single IPv4 /32
>> >
>> >> under this provision.
>> >
>> >> 3. The server must have IPv6 addresses with IPv6
>> >
>> >> connectivity (must be dual-stacked).
>> >
>> >> 4. The receiving organization must demonstrate that it
>> >
>> >> already provides IPv6 addressing and connectivity
>> >
>> >> to at least one additional existing server
>> >
>> >> (organizations which can show 100% dual stack are
>> >
>> >> exempt from this requirement).
>> >
>> >> 5. The receiving organization must IPv6 enable all of
>> >
>> >> their content on the following schedule:
>> >
>> >>
>> >
>> >> + 25% of content IPv6 reachable within six
>> >
>> >> months of receiving their first addresses
>> >
>> >> under this policy
>> >
>> >> + 50% of content IPv6 reachable within one year
>> >
>> >> of receiving their first addresses under this
>> >
>> >> policy
>> >
>> >> + 75% of content IPv6 reachable within 18 months
>> >
>> >> of receiving their first addresses under this
>> >
>> >> policy
>> >
>> >> + 90% of content IPv6 reachable within 24 months
>> >
>> >> of receiving their first addresses under this
>> >
>> >> policy
>> >
>> >> 6. A network providing SSL terminations for applications
>> >
>> >> or content acceleration may receive a /32 for each
>> >
>> >> distinguished name by following all requirements in
>> >
>> >> this provision, substituting "distinguished name" for
>> >
>> >> "server."
>> >
>> >> 7. Networks using these addresses for authoritative
>> >
>> >> DNS servers can use 2 /32s per 1,000 authoritative
>> >
>> >> domains served up to 128 /32s total per organization.
>> >
>> >> 8. The total space issued to all organizations under
>> >
>> >> this provision shall not exceed an aggregate /9
>> >
>> >> or equivalent per /8 placed into the transition pool.
>> >
>> >>
>> >
>> >> (c) An ISP/LIR or End user organization may request a block no
>> >
>> >> smaller than a /29 and no larger than a /25 per quarter for
>> >
>> >> purposes relevant to their ability to deploy IPv6.
>> >
>> >> 1. Space issued under this provision is an assignment,
>> >
>> >> not an allocation. An LIR may not distribute this
>> >
>> >> space to their customers.
>> >
>> >> 2. Space issued under this provision must be used to
>> >
>> >> provide the required public IPv4 address(es) for
>> >
>> >> transitional technologies operated by the recipient
>> >
>> >> organization.
>> >
>> >>
>> >
>> >> Specific examples of permitted uses are:
>> >
>> >> a. Large scale or "Carrier Grade" NAT
>> >
>> >> b. NAT-PT
>> >
>> >> c. DS-LITE/B4/AFTeR
>> >
>> >> d. IVI
>> >
>> >> e. DNS64 or other transitional DNS enablers
>> >
>> >> f. Other technologies of similar purpose
>> >
>> >> and scope.
>> >
>> >>
>> >
>> >> 3. A /10 from the final /8 shall be reserved for
>> >
>> >> issuance
>> >
>> >> under this provision. In no case shall any addresses
>> >
>> >> from this /10 be issued for any purpose outside
>> >
>> >> of 4.10.4(c).
>> >
>> >>
>> >
>> >> (d) Applications which would qualify for IPv4 under section 4.4
>> >
>> >> of
>> >
>> >> the NRPM (critical infrastructure) may qualify for IPv4
>> >
>> >> space
>> >
>> >> under this policy if they meet the following criteria:
>> >
>> >> 1. The critical infrastructure to be numbered must also
>> >
>> >> have IPv6 addresses and must provide all services
>> >
>> >> provided on IPv4 over IPv6 on the same time table.
>> >
>> >> 2. Assignments under this provision shall be the
>> >
>> >> smallest technically feasible size for the critical
>> >
>> >> infrastructure in question.
>> >
>> >> 3. The total space assigned under this provision shall
>> >
>> >> not
>> >
>> >> exceed the equivalent of a /14.
>> >
>> >>
>> >
>> >> 
>> > >> >> >> > >> >>
>> >
>> >>
>> >
>> >>
>> >
>> >> Rationale:
>> >
>> >>
>> >
>> >> The current terminology in section 4.10 is vague and could allow a
>> >
>> >> variety of interpretations which could lead to allocations or
>> >
>> >> assignments being made to ISPs intending to misuse the space for
>> >
>> >> general deployment by using IPv6 overlay technologies as a "IPv6
>> >
>> >> deployments" requiring IPv4 space for transition. For example, the
>> >
>> >> current policy could be interpreted to enable an ISP to require IPv4
>> >
>> >> addresses for all IPv6 customers to roll IPv6 out as 6rd to customers
>> >
>> >> who would be otherwise unable to get IPv4 space. This is clearly
>> >
>> >> outside of the original intent of the proposal which created 4.10 (6rd
>> >
>> >> was not yet envisioned at the time that was written). This proposal
>> >
>> >> seeks to clarify that intent and tighten up the requirements for
>> >
>> >> organizations seeking to get space from this limited final resource so
>> >
>> >> that it truly is available to facilitate transitional technologies.
>> >
>> >>
>> >
>> >> Additionally, there are a number of community segments that are not
>> >
>> >> well served by the original intent of 4.10 and several community
>> >
>> >> members requested a mechanism for providing a certain amount of
>> >
>> >> certainty with regards to obtaining space at the end. While it would be
>> >
>> >> impossible to guarantee organizations all the space they need as runout
>> >
>> >> is upon us, this policy seeks to provide a way for organizations to
>> >
>> >> sign up for and receive a reservation from the final space
>> >
>> >> proportionate to their need. The policy also includes guidelines
>> >
>> >> intended to ensure that this vital community resource is given only to
>> >
>> >> organizations working towards a smooth transition to IPv6 to the
>> >
>> >> benefit of the full community.
>> >
>> >>
>> >
>> >> In order to meet these needs, this policy has become very complex. It
>> >
>> >> is an unfortunate artifact of the complex issue it seeks to address. A
>> >
>> >> great deal of effort has been made to simplify the policy as much as
>> >
>> >> possible, and, special thinks go out to several members of the
>> >
>> >> community for their assistance in this matter.
>> >
>> >>
>> >
>> >> One provision in this draft policy calls for utilization criteria which
>> >
>> >> may be waived by ARIN staff discretion. The intent of this clause is to
>> >
>> >> allow staff to avoid penalizing an organization for successful address
>> >
>> >> conservation efforts.
>> >
>> >>
>> >
>> >> Runout is upon us. IANA will run out of the IANA free pool and issue
>> >
>> >> the last /8 this policy seeks to regulate before the next ARIN public
>> >
>> >> policy meeting. If we are to make any attempt at fair distribution for
>> >
>> >> the sake of IPv6 deployment, this is our final opportunity to do so
>> >
>> >> outside of an emergency action by the ARIN board.
>> >
>> >>
>> >
>> >> Timetable for implementation: immediate
>> >
>> >>
>> >
>> >> For reference, here is the current text of 4.10
>> >
>> >>
>> >
>> >> 4.10 Dedicated IPv4 block to facilitate IPv6 Deployment
>> >
>> >>
>> >
>> >> When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous
>> >
>> >> /10 IPv4 block will be set aside and dedicated to facilitate IPv6
>> >
>> >> deployment. Allocations and assignments from this block must be
>> >
>> >> justified by immediate IPv6 deployment requirements. Examples of such
>> >
>> >> needs include: IPv4 addresses for key dual stack DNS servers, and NAT-
>> >
>> >> PT or NAT464 translators. ARIN staff will use their discretion when
>> >
>> >> evaluating justifications.
>> >
>> >>
>> >
>> >> This block will be subject to a minimum size allocation of /28 and a
>> >
>> >> maximum size allocation of /24. ARIN should use sparse allocation when
>> >
>> >> possible within that /10 block.
>> >
>> >>
>> >
>> >> In order to receive an allocation or assignment under this policy:
>> >
>> >> 1. the applicant may not have received resources under this
>> >
>> >> policy in the preceding six months;
>> >
>> >> 2. previous allocations/assignments under this policy must
>> >
>> >> continue to meet the justification requirements of this policy;
>> >
>> >> 3. previous allocations/assignments under this policy must meet
>> >
>> >> the utilization requirements of end user assignments;
>> >
>> >> 4. the applicant must demonstrate that no other allocations or
>> >
>> >> assignments will meet this need;
>> >
>> >> 5. on subsequent allocation under this policy, ARIN staff may
>> >
>> >> require applicants to renumber out of previously allocated / assigned
>> >
>> >> space under this policy in order to minimize non-contiguous
>> >
>> >> allocations.
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > PPML
>> > You are receiving this message because you are subscribed to
>> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> > Unsubscribe or manage your mailing list subscription at:
>> > http://lists.arin.net/mailman/listinfo/arin-ppml
>> > Please contact info at arin.net if you experience any issues.
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Wed, 29 Sep 2010 08:32:59 -0600
>> From: Chris Grundemann 
>> To: "arin-ppml at arin.net" 
>> Subject: Re: [arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55)
>> Message-ID:
>>        
>> Content-Type: text/plain; charset=windows-1252
>>
>> I think the fact that ARIN Staff is concerned that this policy may
>> favor organizations who are granted reservations too much and Marty
>> believes that it does not go far enough to provide relief to those
>> same organizations illustrates that we have actually found a pretty
>> decent compromise.
>>
>> On Tue, Sep 28, 2010 at 15:55, Hannigan, Martin  wrote:
>> >
>> > This proposal still does not go far enough in offering some level of
>> relief
>> > to all segments of the industry.
>>
>> The simple fact is that we are running out of IPv4 space. Absolutely
>> no policy can change that. Advancing transition to IPv6 across the
>> board is the best way (perhaps the only way) to ease all of our
>> growing pains going forward.
>>
>> > On 9/27/10 4:02 PM, "ARIN"  wrote:
>> >>
>> >> ? A. ? ?ARIN Staff Comments
>> >>
>> >> ? ?? Section 4.10.2 suggests that all allocations made under this
>> policy
>> >> will initially be made from a 3-year reservation. ?In light of the
>> >> imminent depletion of IPv4 address space, it doesn't seem fair to allow
>> >> some organizations to retain/reserve this valuable resource for up to 3
>> >> years while others will be denied.
>>
>> I would like to point out that although the initial reservations are
>> for [now two years], there is a built in "fairness valve" as well.
>> Please see section 4.10.2.1 in the draft policy, which starts thus:
>>
>>        Reservations will be accepted from the time that this policy
>>        is adopted until the day that ARIN can no longer fill regular
>> requests from
>>        space allocated to ARIN by IANA. At that time, if necessary, all
>> reservations
>>        will be reduced by an equal amount to allow them to fit within
>>        the total space available in the transition pool.
>>
>> So everyone who is granted a reservation before run-out gets *some*
>> reservation, although it is not likely that anyone will get the full
>> reservation requested. I think this is the best balance of
>> predictability and inclusiveness possible.
>>
>> Also note the second phase, post-exhaustion, detailed in section
>> 4.10.2.2 which reads:
>>
>>        Reservation requests received after ARIN free pool depletion
>>        as defined in 4.10.2.1 will not be guaranteed. If approved, such
>>        requests will be placed in a queue. As space becomes available in
>>        the transition pool it will be used to provide allotments to
>>        organizations with reservations in the queue on a first-approved
>>        first-served basis. Partially filled allotments will remain at the
>>        front of the queue.
>>
>> So, *everyone* gets a shot at the transition space, and it comes down
>> to how much space ends up being available.
>>
>> Overall, I think we have come up with the best possible (most fair)
>> soft-landing policy under the current constraints (constraints which
>> will only get tighter).
>>
>> ~Chris
>>
>> >>
>> > _______________________________________________
>> > PPML
>> > You are receiving this message because you are subscribed to
>> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> > Unsubscribe or manage your mailing list subscription at:
>> > http://lists.arin.net/mailman/listinfo/arin-ppml
>> > Please contact info at arin.net if you experience any issues.
>> >
>>
>> --
>> @ChrisGrundemann
>> weblog.chrisgrundemann.com
>> www.burningwiththebush.com
>> www.coisoc.org
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> ARIN-PPML mailing list
>> ARIN-PPML at arin.net
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>
>> End of ARIN-PPML Digest, Vol 63, Issue 32
>> *****************************************
>>
>
>
>
> --
>
> Rudi Daniel
> *danielcharles consulting
> **1-784 498 8277
> *
> *
> *
>
>
>  _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
>
>


-- 

Rudi Daniel
*danielcharles consulting
**1-784 498 8277
*
*
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From marty at akamai.com  Thu Sep 30 17:04:28 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Thu, 30 Sep 2010 17:04:28 -0400
Subject: [arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55)
In-Reply-To: <502A0F78-0A9E-444F-A256-6C4445AA60C0@delong.com>
Message-ID: 




On 9/30/10 10:12 AM, "Owen DeLong"  wrote:

> 
> On Sep 30, 2010, at 6:59 AM, Hannigan, Martin wrote:
> 
>> 
>> 
>> 
>> On 9/30/10 9:44 AM, "Owen DeLong"  wrote:
>> 


[ snip ]

>> Ah, no. The theoretical /25's and /18's would have been approved based on
>> need. An equal reduction for all bolsters the equity of needs based
>> allocations. Capping the reduction on the low side is the Robin Hood
>> approach. 
>> 
> Look, at some low side point, one has to cap the reduction. If nothing else,
> it absolutely impossible to hand out a fractional /32.


Which I've demonstrated is financially objectionable especially considering
that the cost of IPv4 address space beyond depletion is an unknown variable.
 
> I think it is impractical to hand out less than a /28.
> 
> I'll point out that you were the one in our earlier discussions who wanted to
> raise this threshold rather than lower it.


We're only discussing these low thresholds because that is how the current
proposal is written and that's what we are discussing. The minimum
allocation should be higher and that the reservation system mechanics are
broken with respect to fairness.


Best,

-M<