From narten at us.ibm.com Fri Feb 6 00:53:02 2015 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 06 Feb 2015 00:53:02 -0500 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201502060553.t165r2VI018543@rotala.raleigh.ibm.com> Total of 1 messages in the last 7 days. script run at: Fri Feb 6 00:53:02 EST 2015 Messages | Bytes | Who --------+------+--------+----------+------------------------ 100.00% | 1 |100.00% | 6552 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 1 |100.00% | 6552 | Total From narten at us.ibm.com Fri Feb 13 00:53:02 2015 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 13 Feb 2015 00:53:02 -0500 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201502130553.t1D5r2hF010234@rotala.raleigh.ibm.com> Total of 1 messages in the last 7 days. script run at: Fri Feb 13 00:53:02 EST 2015 Messages | Bytes | Who --------+------+--------+----------+------------------------ 100.00% | 1 |100.00% | 6421 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 1 |100.00% | 6421 | Total From ggiesen at giesen.me Tue Feb 17 10:36:59 2015 From: ggiesen at giesen.me (Gary T. Giesen) Date: Tue, 17 Feb 2015 10:36:59 -0500 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) Message-ID: <013c01d04ac7$91b10830$b5131890$@giesen.me> PPML, I'd like to discuss what I perceive as a gap in the IPv6 End User policy. Under the NRPM Section 4.3, there are virtually no requirements for an initial IPv4 assignment to end users, other than the minimum allocation size is a /24 and a 50% (128 addresses) within one year. Under the analogous IPv6 section (6.5.8), an End User can only quality for a direct assignment from ARIN if they meet 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 that makes active use of a minimum of 2000 IPv6 addresses within 12 months, or; d. By having a network that makes active use of a minimum of 200 /64 subnets within 12 months, or; e. By providing a reasonable technical justification indicating why IPv6 addresses from an ISP or other LIR are unsuitable. The IPv4 policy has no multihoming requirement, and a vastly lower minimum host count. While the IPv6 policy does try to address some of the economic pain of renumbering, I don't think it goes far enough. Real life scenario: 1) Customer with 50 locations (IPVPN) spread across the country/continent 2) 10 staff per location (average; 500 total) 3) 20 devices per location (average; 1000 total) 4) 2 subnets (voice & data) per location (average, 100 total) 5) Not multihomed 6) Currently using RFC1918 IPv4 space + NAT You may think my example is contrived, but is actually my typical customer. Based on my reading of the NRPM, this customer does not qualify for a direct allocation from ARIN. I'd argue, however that the economic costs to this customer renumbering are far greater than another customer who has 2000 staff or 200 subnets located within a few locations in the same metro area. Now I suppose the simple answer is for my customer is to go get an IPv4 /24 (which would automatically qualify them for an IPv6 allocation under 6.5.8.1 (a)), but I think that's a waste of time and resources when: a) We've accepted NAT in the IPv4 world is a fact of life, but in IPv6 it's the exception rather than the norm b) IPv4 is the constrained resource, yet it seems to be more readily available to end users c) We're hinging IPv6 deployments on IPv4 deployments, which seems counter-intuitive to me (we should be making IPv6 more accessible than IPv4 to encourage adoption, rather than the other way around) I'm actively engaged in convincing my customers to adopt IPv6 (rather than waiting for them to ask for it), but it's a tough sell already without the problem of them having to renumber their entire network should they no longer be my customer. The only alternative left to me is ULA addressing (which still doesn't guarantee uniqueness) + NAT66 (which is still very poorly supported in applications - meaning a poor user experience). I believe it is commonly held amongst this community that IPv6 is supposed to restore the end-to-end principle of the Internet (that is my belief as well), but IPv6 won't get deployed in this fashion if it's going to be too painful to deploy or move. So here's my proposed solution: Make direct assignments available to any end user who qualifies for at least a /40 (13+ sites). I think this addresses most problems with routing table growth (by not handing out a direct /48 to every mom and pop shop out there), addresses most of my customers' concerns with having to renumber dozens of sites, and doesn't force customers to get IPv4 /24's just to get the IPv6 resources they need. Thoughts/criticisms/questions/concerns? GTG -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Tue Feb 17 11:10:19 2015 From: bill at herrin.us (William Herrin) Date: Tue, 17 Feb 2015 11:10:19 -0500 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) In-Reply-To: <013c01d04ac7$91b10830$b5131890$@giesen.me> References: <013c01d04ac7$91b10830$b5131890$@giesen.me> Message-ID: On Tue, Feb 17, 2015 at 10:36 AM, Gary T. Giesen wrote: > The IPv4 policy has no multihoming requirement, and a vastly lower minimum > host count. While the IPv6 policy does try to address some of the economic > pain of renumbering, I don't think it goes far enough. Hi Gary, This is because we're still trying to minimize the number of routes that are announced to the global IPv6 table. It's actually rather expensive for the folks who have to carry those routes and if you can't afford two ISPs then you're not putting the money into the system that covers that cost. Also, the nagging little detail that a single-homed entity loses no raw capability by keeping their prefix out of the core. Some later renumbering hassle, sure, but no actual capabilities. > Now I suppose the simple answer is for my customer is to go get an IPv4 /24 > (which would automatically qualify them for an IPv6 allocation under 6.5.8.1 > (a)), but I think that's a waste of time and resources when: Yeah, the folks who pushed that one through weren't paying close attention to the overall policy impact. Their mistake is your gain; my advice is to game it while you can. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From SRyerse at eclipse-networks.com Tue Feb 17 11:22:49 2015 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Tue, 17 Feb 2015 16:22:49 +0000 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Pleasedon't me make do ULA + NAT66) In-Reply-To: <013c01d04ac7$91b10830$b5131890$@giesen.me> References: <013c01d04ac7$91b10830$b5131890$@giesen.me> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD120174BDDF73@ENI-MAIL.eclipse-networks.com> Your point is valid and I agree that IPv6 doesn?t need those needs tests except maybe for large blocks. The routing table is always an issue, but if we want IPv6 to become the standard we should follow Jon Postel?s model of making it easy to get IPv6 resources. Since there is a yearly fee to get IPv6, organizations will only purchase what they need since they can get more and that is all of the needs testing needed for smaller blocks of IPv6. My two cents. Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 www.eclipse-networks.com 770.656.1460 - Cell 770.399.9099- Office [Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc. Conquering Complex Networks? From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Gary T. Giesen Sent: Tuesday, February 17, 2015 10:37 AM To: arin-ppml at arin.net Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Pleasedon't me make do ULA + NAT66) PPML, I?d like to discuss what I perceive as a gap in the IPv6 End User policy. Under the NRPM Section 4.3, there are virtually no requirements for an initial IPv4 assignment to end users, other than the minimum allocation size is a /24 and a 50% (128 addresses) within one year. Under the analogous IPv6 section (6.5.8), an End User can only quality for a direct assignment from ARIN if they meet 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 that makes active use of a minimum of 2000 IPv6 addresses within 12 months, or; d. By having a network that makes active use of a minimum of 200 /64 subnets within 12 months, or; e. By providing a reasonable technical justification indicating why IPv6 addresses from an ISP or other LIR are unsuitable. The IPv4 policy has no multihoming requirement, and a vastly lower minimum host count. While the IPv6 policy does try to address some of the economic pain of renumbering, I don?t think it goes far enough. Real life scenario: 1) Customer with 50 locations (IPVPN) spread across the country/continent 2) 10 staff per location (average; 500 total) 3) 20 devices per location (average; 1000 total) 4) 2 subnets (voice & data) per location (average, 100 total) 5) Not multihomed 6) Currently using RFC1918 IPv4 space + NAT You may think my example is contrived, but is actually my typical customer. Based on my reading of the NRPM, this customer does not qualify for a direct allocation from ARIN. I?d argue, however that the economic costs to this customer renumbering are far greater than another customer who has 2000 staff or 200 subnets located within a few locations in the same metro area. Now I suppose the simple answer is for my customer is to go get an IPv4 /24 (which would automatically qualify them for an IPv6 allocation under 6.5.8.1 (a)), but I think that?s a waste of time and resources when: a) We?ve accepted NAT in the IPv4 world is a fact of life, but in IPv6 it?s the exception rather than the norm b) IPv4 is the constrained resource, yet it seems to be more readily available to end users c) We?re hinging IPv6 deployments on IPv4 deployments, which seems counter-intuitive to me (we should be making IPv6 more accessible than IPv4 to encourage adoption, rather than the other way around) I?m actively engaged in convincing my customers to adopt IPv6 (rather than waiting for them to ask for it), but it?s a tough sell already without the problem of them having to renumber their entire network should they no longer be my customer. The only alternative left to me is ULA addressing (which still doesn?t guarantee uniqueness) + NAT66 (which is still very poorly supported in applications ? meaning a poor user experience). I believe it is commonly held amongst this community that IPv6 is supposed to restore the end-to-end principle of the Internet (that is my belief as well), but IPv6 won?t get deployed in this fashion if it?s going to be too painful to deploy or move. So here?s my proposed solution: Make direct assignments available to any end user who qualifies for at least a /40 (13+ sites). I think this addresses most problems with routing table growth (by not handing out a direct /48 to every mom and pop shop out there), addresses most of my customers? concerns with having to renumber dozens of sites, and doesn?t force customers to get IPv4 /24?s just to get the IPv6 resources they need. Thoughts/criticisms/questions/concerns? GTG -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1468 bytes Desc: image001.jpg URL: From ggiesen at giesen.me Tue Feb 17 11:30:24 2015 From: ggiesen at giesen.me (Gary T. Giesen) Date: Tue, 17 Feb 2015 11:30:24 -0500 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) In-Reply-To: References: <013c01d04ac7$91b10830$b5131890$@giesen.me> Message-ID: <016f01d04acf$082a9b00$187fd100$@giesen.me> Bill, I understand the implications to the routing table (and why the policy is in place). My argument is that if a customer is large enough to justify a /40, I think they should be able to warrant getting a direct assignment. Note that my specific use case is for IPVPN (ie private networks) which are then single-homed to us for Internet traffic. This is probably not all that unique for an IPVPN customer, since they depend on us for the IPVPN anyways, multihoming for the Internet access doesn't gain them a lot. True that we could force customers to get an ASN and then go multihome to one of our competitors (or go get an IPv4 /24) but all of that seems like a lot of additional hurdles that will hold up adoption of IPv6, particularly for this use case. If you force me to go get an IPv4 /24 for them you're only saving half an IPv6 routing table slot anyways because I'll have to announce the /24, instead of just assigning them out of my IPv4 aggregate block. GTG -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin Sent: February-17-15 11:10 AM To: Gary T. Giesen Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) On Tue, Feb 17, 2015 at 10:36 AM, Gary T. Giesen wrote: > The IPv4 policy has no multihoming requirement, and a vastly lower > minimum host count. While the IPv6 policy does try to address some of > the economic pain of renumbering, I don't think it goes far enough. Hi Gary, This is because we're still trying to minimize the number of routes that are announced to the global IPv6 table. It's actually rather expensive for the folks who have to carry those routes and if you can't afford two ISPs then you're not putting the money into the system that covers that cost. Also, the nagging little detail that a single-homed entity loses no raw capability by keeping their prefix out of the core. Some later renumbering hassle, sure, but no actual capabilities. > Now I suppose the simple answer is for my customer is to go get an > IPv4 /24 (which would automatically qualify them for an IPv6 > allocation under 6.5.8.1 (a)), but I think that's a waste of time and resources when: Yeah, the folks who pushed that one through weren't paying close attention to the overall policy impact. Their mistake is your gain; my advice is to game it while you can. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: _______________________________________________ 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 woody at pch.net Tue Feb 17 11:31:41 2015 From: woody at pch.net (Bill Woodcock) Date: Tue, 17 Feb 2015 08:31:41 -0800 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Pleasedon't me make do ULA + NAT66) In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD120174BDDF73@ENI-MAIL.eclipse-networks.com> References: <013c01d04ac7$91b10830$b5131890$@giesen.me> <5B9E90747FA2974D91A54FCFA1B8AD120174BDDF73@ENI-MAIL.eclipse-networks.com> Message-ID: The point isn't the size of the block, it's the cost of the route. -Bill > On Feb 17, 2015, at 08:23, Steven Ryerse wrote: > > Your point is valid and I agree that IPv6 doesn?t need those needs tests except maybe for large blocks. The routing table is always an issue, but if we want IPv6 to become the standard we should follow Jon Postel?s model of making it easy to get IPv6 resources. Since there is a yearly fee to get IPv6, organizations will only purchase what they need since they can get more and that is all of the needs testing needed for smaller blocks of IPv6. My two cents. > > > Steven Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > www.eclipse-networks.com > 770.656.1460 - Cell > 770.399.9099- Office > > ? Eclipse Networks, Inc. > Conquering Complex Networks? > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Gary T. Giesen > Sent: Tuesday, February 17, 2015 10:37 AM > To: arin-ppml at arin.net > Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Pleasedon't me make do ULA + NAT66) > > PPML, > > I?d like to discuss what I perceive as a gap in the IPv6 End User policy. > > Under the NRPM Section 4.3, there are virtually no requirements for an initial IPv4 assignment to end users, other than the minimum allocation size is a /24 and a 50% (128 addresses) within one year. Under the analogous IPv6 section (6.5.8), an End User can only quality for a direct assignment from ARIN if they meet 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 that makes active use of a minimum of 2000 IPv6 addresses within 12 months, or; > d. By having a network that makes active use of a minimum of 200 /64 subnets within 12 months, or; > e. By providing a reasonable technical justification indicating why IPv6 addresses from an ISP or other LIR are unsuitable. > > > The IPv4 policy has no multihoming requirement, and a vastly lower minimum host count. While the IPv6 policy does try to address some of the economic pain of renumbering, I don?t think it goes far enough. > > Real life scenario: > > 1) Customer with 50 locations (IPVPN) spread across the country/continent > 2) 10 staff per location (average; 500 total) > 3) 20 devices per location (average; 1000 total) > 4) 2 subnets (voice & data) per location (average, 100 total) > 5) Not multihomed > 6) Currently using RFC1918 IPv4 space + NAT > > > You may think my example is contrived, but is actually my typical customer. Based on my reading of the NRPM, this customer does not qualify for a direct allocation from ARIN. I?d argue, however that the economic costs to this customer renumbering are far greater than another customer who has 2000 staff or 200 subnets located within a few locations in the same metro area. > > Now I suppose the simple answer is for my customer is to go get an IPv4 /24 (which would automatically qualify them for an IPv6 allocation under 6.5.8.1 (a)), but I think that?s a waste of time and resources when: > > a) We?ve accepted NAT in the IPv4 world is a fact of life, but in IPv6 it?s the exception rather than the norm > b) IPv4 is the constrained resource, yet it seems to be more readily available to end users > c) We?re hinging IPv6 deployments on IPv4 deployments, which seems counter-intuitive to me (we should be making IPv6 more accessible than IPv4 to encourage adoption, rather than the other way around) > > > I?m actively engaged in convincing my customers to adopt IPv6 (rather than waiting for them to ask for it), but it?s a tough sell already without the problem of them having to renumber their entire network should they no longer be my customer. The only alternative left to me is ULA addressing (which still doesn?t guarantee uniqueness) + NAT66 (which is still very poorly supported in applications ? meaning a poor user experience). I believe it is commonly held amongst this community that IPv6 is supposed to restore the end-to-end principle of the Internet (that is my belief as well), but IPv6 won?t get deployed in this fashion if it?s going to be too painful to deploy or move. > > So here?s my proposed solution: Make direct assignments available to any end user who qualifies for at least a /40 (13+ sites). I think this addresses most problems with routing table growth (by not handing out a direct /48 to every mom and pop shop out there), addresses most of my customers? concerns with having to renumber dozens of sites, and doesn?t force customers to get IPv4 /24?s just to get the IPv6 resources they need. > > Thoughts/criticisms/questions/concerns? > > GTG > > _______________________________________________ > 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 ggiesen at giesen.me Tue Feb 17 11:34:38 2015 From: ggiesen at giesen.me (Gary T. Giesen) Date: Tue, 17 Feb 2015 11:34:38 -0500 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Pleasedon't me make do ULA + NAT66) In-Reply-To: References: <013c01d04ac7$91b10830$b5131890$@giesen.me> <5B9E90747FA2974D91A54FCFA1B8AD120174BDDF73@ENI-MAIL.eclipse-networks.com> Message-ID: <017701d04acf$9f8a21a0$de9e64e0$@giesen.me> Bill, One of the tests for a direct assignment is if renumbering would affect 2000+ users. My argument is that having to renumber a /40 worth of address space because they switch providers is at *least* as painful has having to renumber 2000 users. GTG From: Bill Woodcock [mailto:woody at pch.net] Sent: February-17-15 11:32 AM To: Steven Ryerse Cc: Gary T. Giesen; arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Pleasedon't me make do ULA + NAT66) The point isn't the size of the block, it's the cost of the route. -Bill On Feb 17, 2015, at 08:23, Steven Ryerse wrote: Your point is valid and I agree that IPv6 doesn?t need those needs tests except maybe for large blocks. The routing table is always an issue, but if we want IPv6 to become the standard we should follow Jon Postel?s model of making it easy to get IPv6 resources. Since there is a yearly fee to get IPv6, organizations will only purchase what they need since they can get more and that is all of the needs testing needed for smaller blocks of IPv6. My two cents. Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 www.eclipse-networks.com 770.656.1460 - Cell 770.399.9099- Office ? Eclipse Networks, Inc. Conquering Complex Networks? From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Gary T. Giesen Sent: Tuesday, February 17, 2015 10:37 AM To: arin-ppml at arin.net Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Pleasedon't me make do ULA + NAT66) PPML, I?d like to discuss what I perceive as a gap in the IPv6 End User policy. Under the NRPM Section 4.3, there are virtually no requirements for an initial IPv4 assignment to end users, other than the minimum allocation size is a /24 and a 50% (128 addresses) within one year. Under the analogous IPv6 section (6.5.8), an End User can only quality for a direct assignment from ARIN if they meet 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 that makes active use of a minimum of 2000 IPv6 addresses within 12 months, or; d. By having a network that makes active use of a minimum of 200 /64 subnets within 12 months, or; e. By providing a reasonable technical justification indicating why IPv6 addresses from an ISP or other LIR are unsuitable. The IPv4 policy has no multihoming requirement, and a vastly lower minimum host count. While the IPv6 policy does try to address some of the economic pain of renumbering, I don?t think it goes far enough. Real life scenario: 1) Customer with 50 locations (IPVPN) spread across the country/continent 2) 10 staff per location (average; 500 total) 3) 20 devices per location (average; 1000 total) 4) 2 subnets (voice & data) per location (average, 100 total) 5) Not multihomed 6) Currently using RFC1918 IPv4 space + NAT You may think my example is contrived, but is actually my typical customer. Based on my reading of the NRPM, this customer does not qualify for a direct allocation from ARIN. I?d argue, however that the economic costs to this customer renumbering are far greater than another customer who has 2000 staff or 200 subnets located within a few locations in the same metro area. Now I suppose the simple answer is for my customer is to go get an IPv4 /24 (which would automatically qualify them for an IPv6 allocation under 6.5.8.1 (a)), but I think that?s a waste of time and resources when: a) We?ve accepted NAT in the IPv4 world is a fact of life, but in IPv6 it?s the exception rather than the norm b) IPv4 is the constrained resource, yet it seems to be more readily available to end users c) We?re hinging IPv6 deployments on IPv4 deployments, which seems counter-intuitive to me (we should be making IPv6 more accessible than IPv4 to encourage adoption, rather than the other way around) I?m actively engaged in convincing my customers to adopt IPv6 (rather than waiting for them to ask for it), but it?s a tough sell already without the problem of them having to renumber their entire network should they no longer be my customer. The only alternative left to me is ULA addressing (which still doesn?t guarantee uniqueness) + NAT66 (which is still very poorly supported in applications ? meaning a poor user experience). I believe it is commonly held amongst this community that IPv6 is supposed to restore the end-to-end principle of the Internet (that is my belief as well), but IPv6 won?t get deployed in this fashion if it?s going to be too painful to deploy or move. So here?s my proposed solution: Make direct assignments available to any end user who qualifies for at least a /40 (13+ sites). I think this addresses most problems with routing table growth (by not handing out a direct /48 to every mom and pop shop out there), addresses most of my customers? concerns with having to renumber dozens of sites, and doesn?t force customers to get IPv4 /24?s just to get the IPv6 resources they need. Thoughts/criticisms/questions/concerns? GTG _______________________________________________ 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 David.Huberman at microsoft.com Tue Feb 17 11:38:09 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Tue, 17 Feb 2015 16:38:09 +0000 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) In-Reply-To: <013c01d04ac7$91b10830$b5131890$@giesen.me> References: <013c01d04ac7$91b10830$b5131890$@giesen.me> Message-ID: Apply under e). You'll get approved, I think. David R Huberman Microsoft Corporation Principal, Global IP Addressing ________________________________ From: arin-ppml-bounces at arin.net on behalf of Gary T. Giesen Sent: Tuesday, February 17, 2015 7:36:59 AM To: arin-ppml at arin.net Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) PPML, I?d like to discuss what I perceive as a gap in the IPv6 End User policy. Under the NRPM Section 4.3, there are virtually no requirements for an initial IPv4 assignment to end users, other than the minimum allocation size is a /24 and a 50% (128 addresses) within one year. Under the analogous IPv6 section (6.5.8), an End User can only quality for a direct assignment from ARIN if they meet 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 that makes active use of a minimum of 2000 IPv6 addresses within 12 months, or; d. By having a network that makes active use of a minimum of 200 /64 subnets within 12 months, or; e. By providing a reasonable technical justification indicating why IPv6 addresses from an ISP or other LIR are unsuitable. The IPv4 policy has no multihoming requirement, and a vastly lower minimum host count. While the IPv6 policy does try to address some of the economic pain of renumbering, I don?t think it goes far enough. Real life scenario: 1) Customer with 50 locations (IPVPN) spread across the country/continent 2) 10 staff per location (average; 500 total) 3) 20 devices per location (average; 1000 total) 4) 2 subnets (voice & data) per location (average, 100 total) 5) Not multihomed 6) Currently using RFC1918 IPv4 space + NAT You may think my example is contrived, but is actually my typical customer. Based on my reading of the NRPM, this customer does not qualify for a direct allocation from ARIN. I?d argue, however that the economic costs to this customer renumbering are far greater than another customer who has 2000 staff or 200 subnets located within a few locations in the same metro area. Now I suppose the simple answer is for my customer is to go get an IPv4 /24 (which would automatically qualify them for an IPv6 allocation under 6.5.8.1 (a)), but I think that?s a waste of time and resources when: a) We?ve accepted NAT in the IPv4 world is a fact of life, but in IPv6 it?s the exception rather than the norm b) IPv4 is the constrained resource, yet it seems to be more readily available to end users c) We?re hinging IPv6 deployments on IPv4 deployments, which seems counter-intuitive to me (we should be making IPv6 more accessible than IPv4 to encourage adoption, rather than the other way around) I?m actively engaged in convincing my customers to adopt IPv6 (rather than waiting for them to ask for it), but it?s a tough sell already without the problem of them having to renumber their entire network should they no longer be my customer. The only alternative left to me is ULA addressing (which still doesn?t guarantee uniqueness) + NAT66 (which is still very poorly supported in applications ? meaning a poor user experience). I believe it is commonly held amongst this community that IPv6 is supposed to restore the end-to-end principle of the Internet (that is my belief as well), but IPv6 won?t get deployed in this fashion if it?s going to be too painful to deploy or move. So here?s my proposed solution: Make direct assignments available to any end user who qualifies for at least a /40 (13+ sites). I think this addresses most problems with routing table growth (by not handing out a direct /48 to every mom and pop shop out there), addresses most of my customers? concerns with having to renumber dozens of sites, and doesn?t force customers to get IPv4 /24?s just to get the IPv6 resources they need. Thoughts/criticisms/questions/concerns? GTG -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggiesen at giesen.me Tue Feb 17 11:42:43 2015 From: ggiesen at giesen.me (Gary T. Giesen) Date: Tue, 17 Feb 2015 11:42:43 -0500 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) In-Reply-To: References: <013c01d04ac7$91b10830$b5131890$@giesen.me> Message-ID: <01b101d04ad0$c08f63a0$41ae2ae0$@giesen.me> That's obviously a consideration but I don't want to build an IPv6 adoption model for my customers around something quite so fuzzy where one customer could be approved and another be denied. I prefer something a little more concrete that I can point a customer to an say "apply under this" and it's plain to them (and ARIN) that they qualify. GTG From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Huberman Sent: February-17-15 11:38 AM To: Gary T. Giesen; arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) Apply under e). You'll get approved, I think. David R Huberman Microsoft Corporation Principal, Global IP Addressing _____ From: arin-ppml-bounces at arin.net on behalf of Gary T. Giesen Sent: Tuesday, February 17, 2015 7:36:59 AM To: arin-ppml at arin.net Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) PPML, I'd like to discuss what I perceive as a gap in the IPv6 End User policy. Under the NRPM Section 4.3, there are virtually no requirements for an initial IPv4 assignment to end users, other than the minimum allocation size is a /24 and a 50% (128 addresses) within one year. Under the analogous IPv6 section (6.5.8), an End User can only quality for a direct assignment from ARIN if they meet 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 that makes active use of a minimum of 2000 IPv6 addresses within 12 months, or; d. By having a network that makes active use of a minimum of 200 /64 subnets within 12 months, or; e. By providing a reasonable technical justification indicating why IPv6 addresses from an ISP or other LIR are unsuitable. The IPv4 policy has no multihoming requirement, and a vastly lower minimum host count. While the IPv6 policy does try to address some of the economic pain of renumbering, I don't think it goes far enough. Real life scenario: 1) Customer with 50 locations (IPVPN) spread across the country/continent 2) 10 staff per location (average; 500 total) 3) 20 devices per location (average; 1000 total) 4) 2 subnets (voice & data) per location (average, 100 total) 5) Not multihomed 6) Currently using RFC1918 IPv4 space + NAT You may think my example is contrived, but is actually my typical customer. Based on my reading of the NRPM, this customer does not qualify for a direct allocation from ARIN. I'd argue, however that the economic costs to this customer renumbering are far greater than another customer who has 2000 staff or 200 subnets located within a few locations in the same metro area. Now I suppose the simple answer is for my customer is to go get an IPv4 /24 (which would automatically qualify them for an IPv6 allocation under 6.5.8.1 (a)), but I think that's a waste of time and resources when: a) We've accepted NAT in the IPv4 world is a fact of life, but in IPv6 it's the exception rather than the norm b) IPv4 is the constrained resource, yet it seems to be more readily available to end users c) We're hinging IPv6 deployments on IPv4 deployments, which seems counter-intuitive to me (we should be making IPv6 more accessible than IPv4 to encourage adoption, rather than the other way around) I'm actively engaged in convincing my customers to adopt IPv6 (rather than waiting for them to ask for it), but it's a tough sell already without the problem of them having to renumber their entire network should they no longer be my customer. The only alternative left to me is ULA addressing (which still doesn't guarantee uniqueness) + NAT66 (which is still very poorly supported in applications - meaning a poor user experience). I believe it is commonly held amongst this community that IPv6 is supposed to restore the end-to-end principle of the Internet (that is my belief as well), but IPv6 won't get deployed in this fashion if it's going to be too painful to deploy or move. So here's my proposed solution: Make direct assignments available to any end user who qualifies for at least a /40 (13+ sites). I think this addresses most problems with routing table growth (by not handing out a direct /48 to every mom and pop shop out there), addresses most of my customers' concerns with having to renumber dozens of sites, and doesn't force customers to get IPv4 /24's just to get the IPv6 resources they need. Thoughts/criticisms/questions/concerns? GTG -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Huberman at microsoft.com Tue Feb 17 11:54:21 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Tue, 17 Feb 2015 16:54:21 +0000 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) In-Reply-To: <01b101d04ad0$c08f63a0$41ae2ae0$@giesen.me> References: <013c01d04ac7$91b10830$b5131890$@giesen.me> <01b101d04ad0$c08f63a0$41ae2ae0$@giesen.me> Message-ID: But "something quite so fuzzy" is your interpretation, not ARIN's. So let's get ARIN's interpretation and try and take the fuzziness out of the equation. Question for ARIN: In the general (normal) case when an application is made for EU v6 under clause e) and there's a technical explanation for why they want RIR-issued space, will the application be approved ? From: Gary T. Giesen [mailto:ggiesen at giesen.me] Sent: Tuesday, February 17, 2015 8:43 AM To: David Huberman; arin-ppml at arin.net Subject: RE: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) That's obviously a consideration but I don't want to build an IPv6 adoption model for my customers around something quite so fuzzy where one customer could be approved and another be denied. I prefer something a little more concrete that I can point a customer to an say "apply under this" and it's plain to them (and ARIN) that they qualify. GTG From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Huberman Sent: February-17-15 11:38 AM To: Gary T. Giesen; arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) Apply under e). You'll get approved, I think. David R Huberman Microsoft Corporation Principal, Global IP Addressing ________________________________ From: arin-ppml-bounces at arin.net > on behalf of Gary T. Giesen > Sent: Tuesday, February 17, 2015 7:36:59 AM To: arin-ppml at arin.net Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) PPML, I'd like to discuss what I perceive as a gap in the IPv6 End User policy. Under the NRPM Section 4.3, there are virtually no requirements for an initial IPv4 assignment to end users, other than the minimum allocation size is a /24 and a 50% (128 addresses) within one year. Under the analogous IPv6 section (6.5.8), an End User can only quality for a direct assignment from ARIN if they meet 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 that makes active use of a minimum of 2000 IPv6 addresses within 12 months, or; d. By having a network that makes active use of a minimum of 200 /64 subnets within 12 months, or; e. By providing a reasonable technical justification indicating why IPv6 addresses from an ISP or other LIR are unsuitable. The IPv4 policy has no multihoming requirement, and a vastly lower minimum host count. While the IPv6 policy does try to address some of the economic pain of renumbering, I don't think it goes far enough. Real life scenario: 1) Customer with 50 locations (IPVPN) spread across the country/continent 2) 10 staff per location (average; 500 total) 3) 20 devices per location (average; 1000 total) 4) 2 subnets (voice & data) per location (average, 100 total) 5) Not multihomed 6) Currently using RFC1918 IPv4 space + NAT You may think my example is contrived, but is actually my typical customer. Based on my reading of the NRPM, this customer does not qualify for a direct allocation from ARIN. I'd argue, however that the economic costs to this customer renumbering are far greater than another customer who has 2000 staff or 200 subnets located within a few locations in the same metro area. Now I suppose the simple answer is for my customer is to go get an IPv4 /24 (which would automatically qualify them for an IPv6 allocation under 6.5.8.1 (a)), but I think that's a waste of time and resources when: a) We've accepted NAT in the IPv4 world is a fact of life, but in IPv6 it's the exception rather than the norm b) IPv4 is the constrained resource, yet it seems to be more readily available to end users c) We're hinging IPv6 deployments on IPv4 deployments, which seems counter-intuitive to me (we should be making IPv6 more accessible than IPv4 to encourage adoption, rather than the other way around) I'm actively engaged in convincing my customers to adopt IPv6 (rather than waiting for them to ask for it), but it's a tough sell already without the problem of them having to renumber their entire network should they no longer be my customer. The only alternative left to me is ULA addressing (which still doesn't guarantee uniqueness) + NAT66 (which is still very poorly supported in applications - meaning a poor user experience). I believe it is commonly held amongst this community that IPv6 is supposed to restore the end-to-end principle of the Internet (that is my belief as well), but IPv6 won't get deployed in this fashion if it's going to be too painful to deploy or move. So here's my proposed solution: Make direct assignments available to any end user who qualifies for at least a /40 (13+ sites). I think this addresses most problems with routing table growth (by not handing out a direct /48 to every mom and pop shop out there), addresses most of my customers' concerns with having to renumber dozens of sites, and doesn't force customers to get IPv4 /24's just to get the IPv6 resources they need. Thoughts/criticisms/questions/concerns? GTG -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Tue Feb 17 12:09:01 2015 From: jcurran at arin.net (John Curran) Date: Tue, 17 Feb 2015 17:09:01 +0000 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) In-Reply-To: References: <013c01d04ac7$91b10830$b5131890$@giesen.me> <01b101d04ad0$c08f63a0$41ae2ae0$@giesen.me> Message-ID: On Feb 17, 2015, at 11:54 AM, David Huberman > wrote: But ?something quite so fuzzy? is your interpretation, not ARIN?s. So let?s get ARIN?s interpretation and try and take the fuzziness out of the equation. Question for ARIN: In the general (normal) case when an application is made for EU v6 under clause e) and there?s a technical explanation for why they want RIR-issued space, will the application be approved ? Yes, so long as a technical explanation is provided. NRPM 6.5.8.1 provides a list of several situations that would warrant direct end-user IPv6 assignment, and others are accepted as well so long as a reasonable technical justification is provided. Thanks, /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggiesen at giesen.me Tue Feb 17 12:21:19 2015 From: ggiesen at giesen.me (Gary T. Giesen) Date: Tue, 17 Feb 2015 12:21:19 -0500 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) Message-ID: <01f801d04ad6$24f2c0d0$6ed84270$@giesen.me> My concern is that the thresholds for a direct assignment are already specified in 6.5.8.1 a through d, which my example customer would not qualify under any of them. What I?m asking for is essentially a fifth criteria (other than reasonable technical justification) - ?By having a network that has at least 13 sites? as I?m know sure you qualify ?not wanting to renumber? as a reasonable technical justification. Clearly c) and d) are in place to reduce the pain of renumbering for larger customers, I?m just arguing my example customer?s pain at renumbering is at least as great as anyone who qualifies under either c) or d) and deserves a direct assignment. John, Are you able to speak to the specific scenario I?ve previously laid out (and whether ARIN would approve such a request under 6.5.8.1e)? GTG From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Curran Sent: February-17-15 12:09 PM To: David R Huberman Cc: Gary T. Giesen; arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) On Feb 17, 2015, at 11:54 AM, David Huberman wrote: But ?something quite so fuzzy? is your interpretation, not ARIN?s. So let?s get ARIN?s interpretation and try and take the fuzziness out of the equation. Question for ARIN: In the general (normal) case when an application is made for EU v6 under clause e) and there?s a technical explanation for why they want RIR-issued space, will the application be approved ? Yes, so long as a technical explanation is provided. NRPM 6.5.8.1 provides a list of several situations that would warrant direct end-user IPv6 assignment, and others are accepted as well so long as a reasonable technical justification is provided. Thanks, /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Huberman at microsoft.com Tue Feb 17 12:39:04 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Tue, 17 Feb 2015 17:39:04 +0000 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) In-Reply-To: References: <013c01d04ac7$91b10830$b5131890$@giesen.me> <01b101d04ad0$c08f63a0$41ae2ae0$@giesen.me> Message-ID: Thank you John! So Gary: I understand your meta point. I am all for clarity and ease-of-use in the NRPM. As an AC member, I hope to drive the NRPM to more and more ?easiness?. But (and perhaps I?m wrong), I feel that EU v6 policy is pretty needs-free and easy. You have 5 clauses to qualify under, and clause e) really is the ?catch-all? bucket for ?everything else?, including the case you brought up. Disagree? David R Huberman Microsoft Corporation Principal, Global IP Addressing From: John Curran [mailto:jcurran at arin.net] Sent: Tuesday, February 17, 2015 9:09 AM To: David Huberman Cc: Gary T. Giesen; arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) On Feb 17, 2015, at 11:54 AM, David Huberman > wrote: But ?something quite so fuzzy? is your interpretation, not ARIN?s. So let?s get ARIN?s interpretation and try and take the fuzziness out of the equation. Question for ARIN: In the general (normal) case when an application is made for EU v6 under clause e) and there?s a technical explanation for why they want RIR-issued space, will the application be approved ? Yes, so long as a technical explanation is provided. NRPM 6.5.8.1 provides a list of several situations that would warrant direct end-user IPv6 assignment, and others are accepted as well so long as a reasonable technical justification is provided. Thanks, /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggiesen at giesen.me Tue Feb 17 12:54:53 2015 From: ggiesen at giesen.me (Gary T. Giesen) Date: Tue, 17 Feb 2015 12:54:53 -0500 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) In-Reply-To: References: <013c01d04ac7$91b10830$b5131890$@giesen.me> <01b101d04ad0$c08f63a0$41ae2ae0$@giesen.me> Message-ID: <023201d04ada$d5577930$80066b90$@giesen.me> David, I don?t necessarily disagree. Just trying to minimize the business risk of having to have virtually all of my customers qualify under e) with the risk of rejection because my use case isn?t specifically spelled out. And I realize perhaps my use case is a very small minority. But the barriers to adoption are real and if I can?t check a box and guarantee my customers get address space when they need it, they won?t adopt, plain and simple. Perhaps I?ll feel a bit better about it when I have a few 6.5.8.1e applications under my belt. GTG From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Huberman Sent: February-17-15 12:39 PM To: John Curran Cc: Gary T. Giesen; arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) Thank you John! So Gary: I understand your meta point. I am all for clarity and ease-of-use in the NRPM. As an AC member, I hope to drive the NRPM to more and more ?easiness?. But (and perhaps I?m wrong), I feel that EU v6 policy is pretty needs-free and easy. You have 5 clauses to qualify under, and clause e) really is the ?catch-all? bucket for ?everything else?, including the case you brought up. Disagree? David R Huberman Microsoft Corporation Principal, Global IP Addressing From: John Curran [mailto:jcurran at arin.net] Sent: Tuesday, February 17, 2015 9:09 AM To: David Huberman Cc: Gary T. Giesen; arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) On Feb 17, 2015, at 11:54 AM, David Huberman wrote: But ?something quite so fuzzy? is your interpretation, not ARIN?s. So let?s get ARIN?s interpretation and try and take the fuzziness out of the equation. Question for ARIN: In the general (normal) case when an application is made for EU v6 under clause e) and there?s a technical explanation for why they want RIR-issued space, will the application be approved ? Yes, so long as a technical explanation is provided. NRPM 6.5.8.1 provides a list of several situations that would warrant direct end-user IPv6 assignment, and others are accepted as well so long as a reasonable technical justification is provided. Thanks, /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Huberman at microsoft.com Tue Feb 17 12:59:58 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Tue, 17 Feb 2015 17:59:58 +0000 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) In-Reply-To: <023201d04ada$d5577930$80066b90$@giesen.me> References: <013c01d04ac7$91b10830$b5131890$@giesen.me> <01b101d04ad0$c08f63a0$41ae2ae0$@giesen.me> <023201d04ada$d5577930$80066b90$@giesen.me> Message-ID: Gary, That resonates with me. I agree with you that obtaining IPv6 from the RIR needs to be a sure thing, not a risk, for any network operator who needs PI v6 to sanely build their network. Do you have a general or any specific recommendation for capturing this in policy better than the current text does? David From: Gary T. Giesen [mailto:ggiesen at giesen.me] Sent: Tuesday, February 17, 2015 9:55 AM To: David Huberman; 'John Curran' Cc: arin-ppml at arin.net Subject: RE: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) David, I don?t necessarily disagree. Just trying to minimize the business risk of having to have virtually all of my customers qualify under e) with the risk of rejection because my use case isn?t specifically spelled out. And I realize perhaps my use case is a very small minority. But the barriers to adoption are real and if I can?t check a box and guarantee my customers get address space when they need it, they won?t adopt, plain and simple. Perhaps I?ll feel a bit better about it when I have a few 6.5.8.1e applications under my belt. GTG From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Huberman Sent: February-17-15 12:39 PM To: John Curran Cc: Gary T. Giesen; arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) Thank you John! So Gary: I understand your meta point. I am all for clarity and ease-of-use in the NRPM. As an AC member, I hope to drive the NRPM to more and more ?easiness?. But (and perhaps I?m wrong), I feel that EU v6 policy is pretty needs-free and easy. You have 5 clauses to qualify under, and clause e) really is the ?catch-all? bucket for ?everything else?, including the case you brought up. Disagree? David R Huberman Microsoft Corporation Principal, Global IP Addressing From: John Curran [mailto:jcurran at arin.net] Sent: Tuesday, February 17, 2015 9:09 AM To: David Huberman Cc: Gary T. Giesen; arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) On Feb 17, 2015, at 11:54 AM, David Huberman > wrote: But ?something quite so fuzzy? is your interpretation, not ARIN?s. So let?s get ARIN?s interpretation and try and take the fuzziness out of the equation. Question for ARIN: In the general (normal) case when an application is made for EU v6 under clause e) and there?s a technical explanation for why they want RIR-issued space, will the application be approved ? Yes, so long as a technical explanation is provided. NRPM 6.5.8.1 provides a list of several situations that would warrant direct end-user IPv6 assignment, and others are accepted as well so long as a reasonable technical justification is provided. Thanks, /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Tue Feb 17 13:06:22 2015 From: bill at herrin.us (William Herrin) Date: Tue, 17 Feb 2015 13:06:22 -0500 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) In-Reply-To: <023201d04ada$d5577930$80066b90$@giesen.me> References: <013c01d04ac7$91b10830$b5131890$@giesen.me> <01b101d04ad0$c08f63a0$41ae2ae0$@giesen.me> <023201d04ada$d5577930$80066b90$@giesen.me> Message-ID: On Tue, Feb 17, 2015 at 12:54 PM, Gary T. Giesen wrote: > I don't necessarily disagree. Just trying to minimize the business risk of > having to have virtually all of my customers qualify under e) with the risk > of rejection because my use case isn't specifically spelled out. Hi Gary, When your use case is within an inch or two the one we'd like to prevent, 50 new routes in the table, each serving 10 people on average, business risk kinda goes with the territory. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From ggiesen at giesen.me Tue Feb 17 13:08:57 2015 From: ggiesen at giesen.me (Gary T. Giesen) Date: Tue, 17 Feb 2015 13:08:57 -0500 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) In-Reply-To: References: <013c01d04ac7$91b10830$b5131890$@giesen.me> <01b101d04ad0$c08f63a0$41ae2ae0$@giesen.me> <023201d04ada$d5577930$80066b90$@giesen.me> Message-ID: <024b01d04adc$ccb1a880$6614f980$@giesen.me> We're not talking 50 new routes. We're talking about an aggregate /40. GTG -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin Sent: February-17-15 1:06 PM To: Gary T. Giesen Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) On Tue, Feb 17, 2015 at 12:54 PM, Gary T. Giesen wrote: > I don't necessarily disagree. Just trying to minimize the business > risk of having to have virtually all of my customers qualify under e) > with the risk of rejection because my use case isn't specifically spelled out. Hi Gary, When your use case is within an inch or two the one we'd like to prevent, 50 new routes in the table, each serving 10 people on average, business risk kinda goes with the territory. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: _______________________________________________ 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 ggiesen at giesen.me Tue Feb 17 13:10:58 2015 From: ggiesen at giesen.me (Gary T. Giesen) Date: Tue, 17 Feb 2015 13:10:58 -0500 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) In-Reply-To: References: <013c01d04ac7$91b10830$b5131890$@giesen.me> <01b101d04ad0$c08f63a0$41ae2ae0$@giesen.me> <023201d04ada$d5577930$80066b90$@giesen.me> Message-ID: <025901d04add$14a1a4b0$3de4ee10$@giesen.me> Replace the contents of 6.5.8.1 with: 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 that makes active use of a minimum of 2000 IPv6 addresses within 12 months, or; d. By having a network that makes active use of a minimum of 200 /64 subnets within 12 months, or; e. By having a network that has at least 13 sites (as defined by NRPM 2.10) within one contiguous network, or; f. By providing a reasonable technical justification indicating why IPv6 addresses from an ISP or other LIR are unsuitable. Basically renumbered from e. to f. and added e. GTG From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Huberman Sent: February-17-15 1:00 PM To: Gary T. Giesen; 'John Curran' Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) Gary, That resonates with me. I agree with you that obtaining IPv6 from the RIR needs to be a sure thing, not a risk, for any network operator who needs PI v6 to sanely build their network. Do you have a general or any specific recommendation for capturing this in policy better than the current text does? David From: Gary T. Giesen [mailto:ggiesen at giesen.me] Sent: Tuesday, February 17, 2015 9:55 AM To: David Huberman; 'John Curran' Cc: arin-ppml at arin.net Subject: RE: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) David, I don?t necessarily disagree. Just trying to minimize the business risk of having to have virtually all of my customers qualify under e) with the risk of rejection because my use case isn?t specifically spelled out. And I realize perhaps my use case is a very small minority. But the barriers to adoption are real and if I can?t check a box and guarantee my customers get address space when they need it, they won?t adopt, plain and simple. Perhaps I?ll feel a bit better about it when I have a few 6.5.8.1e applications under my belt. GTG From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Huberman Sent: February-17-15 12:39 PM To: John Curran Cc: Gary T. Giesen; arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) Thank you John! So Gary: I understand your meta point. I am all for clarity and ease-of-use in the NRPM. As an AC member, I hope to drive the NRPM to more and more ?easiness?. But (and perhaps I?m wrong), I feel that EU v6 policy is pretty needs-free and easy. You have 5 clauses to qualify under, and clause e) really is the ?catch-all? bucket for ?everything else?, including the case you brought up. Disagree? David R Huberman Microsoft Corporation Principal, Global IP Addressing From: John Curran [mailto:jcurran at arin.net] Sent: Tuesday, February 17, 2015 9:09 AM To: David Huberman Cc: Gary T. Giesen; arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) On Feb 17, 2015, at 11:54 AM, David Huberman wrote: But ?something quite so fuzzy? is your interpretation, not ARIN?s. So let?s get ARIN?s interpretation and try and take the fuzziness out of the equation. Question for ARIN: In the general (normal) case when an application is made for EU v6 under clause e) and there?s a technical explanation for why they want RIR-issued space, will the application be approved ? Yes, so long as a technical explanation is provided. NRPM 6.5.8.1 provides a list of several situations that would warrant direct end-user IPv6 assignment, and others are accepted as well so long as a reasonable technical justification is provided. Thanks, /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcr at sandelman.ca Tue Feb 17 15:41:32 2015 From: mcr at sandelman.ca (Michael Richardson) Date: Tue, 17 Feb 2015 15:41:32 -0500 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) In-Reply-To: <01b101d04ad0$c08f63a0$41ae2ae0$@giesen.me> References: <013c01d04ac7$91b10830$b5131890$@giesen.me> <01b101d04ad0$c08f63a0$41ae2ae0$@giesen.me> Message-ID: <3625.1424205692@sandelman.ca> Gary T. Giesen wrote: > That's obviously a consideration but I don't want to build an IPv6 > adoption model for my customers around something quite so fuzzy where > one customer could be approved and another be denied. I prefer > something a little more concrete that I can point a customer to an say > "apply under this" and it's plain to them (and ARIN) that they qualify. I completely hear you. I've argued repeatedly (back to 2007) that this BS about routing slots is onsense, and that these kinds of policies are preventing adoption of IPv6 by small and middle sized enterprises. It's just not ARIN's job to protect routing slots. I'm not clear if the resulting /40 will be announced at all. If it will remain internal with IPVPN, and then, with a PI prefix from each *local* ISP, then you have the classic Non-Connected Network. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From David.Huberman at microsoft.com Tue Feb 17 15:45:44 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Tue, 17 Feb 2015 20:45:44 +0000 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) In-Reply-To: <3625.1424205692@sandelman.ca> References: <013c01d04ac7$91b10830$b5131890$@giesen.me> <01b101d04ad0$c08f63a0$41ae2ae0$@giesen.me> <3625.1424205692@sandelman.ca> Message-ID: Michael, Does Gary's concrete suggestion -- adding a qualifier that you can get approved for IPv6 space if you have 13 more sites, with no other criteria -- make sense to you? Would you support it? Thanks, David -----Original Message----- From: mcr at sandelman.ca [mailto:mcr at sandelman.ca] Sent: Tuesday, February 17, 2015 12:42 PM To: Gary T. Giesen Cc: David Huberman; arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) Gary T. Giesen wrote: > That's obviously a consideration but I don't want to build an IPv6 > adoption model for my customers around something quite so fuzzy where > one customer could be approved and another be denied. I prefer > something a little more concrete that I can point a customer to an say > "apply under this" and it's plain to them (and ARIN) that they qualify. I completely hear you. I've argued repeatedly (back to 2007) that this BS about routing slots is onsense, and that these kinds of policies are preventing adoption of IPv6 by small and middle sized enterprises. It's just not ARIN's job to protect routing slots. I'm not clear if the resulting /40 will be announced at all. If it will remain internal with IPVPN, and then, with a PI prefix from each *local* ISP, then you have the classic Non-Connected Network. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From SRyerse at eclipse-networks.com Tue Feb 17 15:47:44 2015 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Tue, 17 Feb 2015 20:47:44 +0000 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Pleasedon't me make do ULA + NAT66) In-Reply-To: References: <013c01d04ac7$91b10830$b5131890$@giesen.me><01b101d04ad0$c08f 63a0$41ae2ae0$@giesen.me><3625.1424205692@sandelman.ca> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD120174BDEE31@ENI-MAIL.eclipse-networks.com> Why 13? How about 3 or more? Real life doesn't always fit neatly into a policy. Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA? 30338 770.656.1460 - Cell 770.399.9099- Office ? Eclipse Networks, Inc. ??????? Conquering Complex Networks? -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Huberman Sent: Tuesday, February 17, 2015 3:46 PM To: mcr at sandelman.ca; Gary T. Giesen Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Pleasedon't me make do ULA + NAT66) Michael, Does Gary's concrete suggestion -- adding a qualifier that you can get approved for IPv6 space if you have 13 more sites, with no other criteria -- make sense to you? Would you support it? Thanks, David -----Original Message----- From: mcr at sandelman.ca [mailto:mcr at sandelman.ca] Sent: Tuesday, February 17, 2015 12:42 PM To: Gary T. Giesen Cc: David Huberman; arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) Gary T. Giesen wrote: > That's obviously a consideration but I don't want to build an IPv6 > adoption model for my customers around something quite so fuzzy where > one customer could be approved and another be denied. I prefer > something a little more concrete that I can point a customer to an say > "apply under this" and it's plain to them (and ARIN) that they qualify. I completely hear you. I've argued repeatedly (back to 2007) that this BS about routing slots is onsense, and that these kinds of policies are preventing adoption of IPv6 by small and middle sized enterprises. It's just not ARIN's job to protect routing slots. I'm not clear if the resulting /40 will be announced at all. If it will remain internal with IPVPN, and then, with a PI prefix from each *local* ISP, then you have the classic Non-Connected Network. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ _______________________________________________ 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 ggiesen at giesen.me Tue Feb 17 16:43:32 2015 From: ggiesen at giesen.me (Gary T. Giesen) Date: Tue, 17 Feb 2015 16:43:32 -0500 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Pleasedon't me make do ULA + NAT66) In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD120174BDEE31@ENI-MAIL.eclipse-networks.com> References: <013c01d04ac7$91b10830$b5131890$@giesen.me><01b101d04ad0$c08f 63a0$41ae2ae0$@giesen.me><3625.1424205692@sandelman.ca> <5B9E90747FA2974D91A54FCFA1B8AD120174BDEE31@ENI-MAIL.eclipse-networks.com> Message-ID: <030201d04afa$c6ec2ab0$54c48010$@giesen.me> Just for clarification, the resulting /40 will be announced as a single prefix. In *theory* it could be announced as its constituent /48's, but since the customer is not multihomed there is not a lot of incentive to do so (and if the customer was multihomed they would qualify under 6.5.8.1b anyways). I came up with 13 based on NRPM 6.5.8.2, which specifies that 13 sites (which is more than 75% of a /44 and thereby qualifies the customer for a /40). GTG -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Steven Ryerse Sent: February-17-15 3:48 PM To: David Huberman; mcr at sandelman.ca; Gary T. Giesen Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Pleasedon't me make do ULA + NAT66) Why 13? How about 3 or more? Real life doesn't always fit neatly into a policy. Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099- Office ? Eclipse Networks, Inc. Conquering Complex Networks? -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Huberman Sent: Tuesday, February 17, 2015 3:46 PM To: mcr at sandelman.ca; Gary T. Giesen Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Pleasedon't me make do ULA + NAT66) Michael, Does Gary's concrete suggestion -- adding a qualifier that you can get approved for IPv6 space if you have 13 more sites, with no other criteria -- make sense to you? Would you support it? Thanks, David -----Original Message----- From: mcr at sandelman.ca [mailto:mcr at sandelman.ca] Sent: Tuesday, February 17, 2015 12:42 PM To: Gary T. Giesen Cc: David Huberman; arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) Gary T. Giesen wrote: > That's obviously a consideration but I don't want to build an IPv6 > adoption model for my customers around something quite so fuzzy where > one customer could be approved and another be denied. I prefer > something a little more concrete that I can point a customer to an say > "apply under this" and it's plain to them (and ARIN) that they qualify. I completely hear you. I've argued repeatedly (back to 2007) that this BS about routing slots is onsense, and that these kinds of policies are preventing adoption of IPv6 by small and middle sized enterprises. It's just not ARIN's job to protect routing slots. I'm not clear if the resulting /40 will be announced at all. If it will remain internal with IPVPN, and then, with a PI prefix from each *local* ISP, then you have the classic Non-Connected Network. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ _______________________________________________ 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 ggiesen at giesen.me Tue Feb 17 16:46:15 2015 From: ggiesen at giesen.me (Gary T. Giesen) Date: Tue, 17 Feb 2015 16:46:15 -0500 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Pleasedon't me make do ULA + NAT66) In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD120174BDEE31@ENI-MAIL.eclipse-networks.com> References: <013c01d04ac7$91b10830$b5131890$@giesen.me><01b101d04ad0$c08f 63a0$41ae2ae0$@giesen.me><3625.1424205692@sandelman.ca> <5B9E90747FA2974D91A54FCFA1B8AD120174BDEE31@ENI-MAIL.eclipse-networks.com> Message-ID: <030401d04afb$27ab7860$77026920$@giesen.me> Just to be clear, I'd love to have any customer that qualifies for a /44 or more be eligible, but I thought that was a pretty low bar and would face significant resistance from the community. GTG -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Steven Ryerse Sent: February-17-15 3:48 PM To: David Huberman; mcr at sandelman.ca; Gary T. Giesen Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Pleasedon't me make do ULA + NAT66) Why 13? How about 3 or more? Real life doesn't always fit neatly into a policy. Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099- Office ? Eclipse Networks, Inc. Conquering Complex Networks? -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Huberman Sent: Tuesday, February 17, 2015 3:46 PM To: mcr at sandelman.ca; Gary T. Giesen Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Pleasedon't me make do ULA + NAT66) Michael, Does Gary's concrete suggestion -- adding a qualifier that you can get approved for IPv6 space if you have 13 more sites, with no other criteria -- make sense to you? Would you support it? Thanks, David -----Original Message----- From: mcr at sandelman.ca [mailto:mcr at sandelman.ca] Sent: Tuesday, February 17, 2015 12:42 PM To: Gary T. Giesen Cc: David Huberman; arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) Gary T. Giesen wrote: > That's obviously a consideration but I don't want to build an IPv6 > adoption model for my customers around something quite so fuzzy where > one customer could be approved and another be denied. I prefer > something a little more concrete that I can point a customer to an say > "apply under this" and it's plain to them (and ARIN) that they qualify. I completely hear you. I've argued repeatedly (back to 2007) that this BS about routing slots is onsense, and that these kinds of policies are preventing adoption of IPv6 by small and middle sized enterprises. It's just not ARIN's job to protect routing slots. I'm not clear if the resulting /40 will be announced at all. If it will remain internal with IPVPN, and then, with a PI prefix from each *local* ISP, then you have the classic Non-Connected Network. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ _______________________________________________ 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 ggiesen at giesen.me Tue Feb 17 16:49:16 2015 From: ggiesen at giesen.me (Gary T. Giesen) Date: Tue, 17 Feb 2015 16:49:16 -0500 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) In-Reply-To: References: <013c01d04ac7$91b10830$b5131890$@giesen.me> <01b101d04ad0$c08f63a0$41ae2ae0$@giesen.me> <3625.1424205692@sandelman.ca> Message-ID: <030601d04afb$93d59840$bb80c8c0$@giesen.me> FYI to try to address Bill Herrin's concern, I amended that they be 13 sites in a contiguous network to try to reduce the probability that there be 13 separate announcements, although I'm not sure how enforceable such a provision would be. GTG -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Huberman Sent: February-17-15 3:46 PM To: mcr at sandelman.ca; Gary T. Giesen Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) Michael, Does Gary's concrete suggestion -- adding a qualifier that you can get approved for IPv6 space if you have 13 more sites, with no other criteria -- make sense to you? Would you support it? Thanks, David -----Original Message----- From: mcr at sandelman.ca [mailto:mcr at sandelman.ca] Sent: Tuesday, February 17, 2015 12:42 PM To: Gary T. Giesen Cc: David Huberman; arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) Gary T. Giesen wrote: > That's obviously a consideration but I don't want to build an IPv6 > adoption model for my customers around something quite so fuzzy where > one customer could be approved and another be denied. I prefer > something a little more concrete that I can point a customer to an say > "apply under this" and it's plain to them (and ARIN) that they qualify. I completely hear you. I've argued repeatedly (back to 2007) that this BS about routing slots is onsense, and that these kinds of policies are preventing adoption of IPv6 by small and middle sized enterprises. It's just not ARIN's job to protect routing slots. I'm not clear if the resulting /40 will be announced at all. If it will remain internal with IPVPN, and then, with a PI prefix from each *local* ISP, then you have the classic Non-Connected Network. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ _______________________________________________ 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 hvgeekwtrvl at gmail.com Tue Feb 17 17:41:32 2015 From: hvgeekwtrvl at gmail.com (james machado) Date: Tue, 17 Feb 2015 14:41:32 -0800 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) In-Reply-To: <030601d04afb$93d59840$bb80c8c0$@giesen.me> References: <013c01d04ac7$91b10830$b5131890$@giesen.me> <01b101d04ad0$c08f63a0$41ae2ae0$@giesen.me> <3625.1424205692@sandelman.ca> <030601d04afb$93d59840$bb80c8c0$@giesen.me> Message-ID: It seems to me, and I am sure I don't know or have all the answers, that there is a disconnect going on in this discussion. On one hand there is the great cry of v4 is running out and everybody should/must move to v6 because addresses are plentiful and this is the future. On the other we are getting the "we don't offer it because nobody asks for it". Someplace in the middle of all this is the - you can't have v6 addresses because you don't a) have enough nodes/networks or b) already have v4 space (which you probably can't qualify for and if you could we don't have any to give you) or c) your not worthy of space in the routing table even if you could get the assignment. Now I don't know how much it costs for a v6 route in the global table so I can't speak to that. What I find interesting is that we know that at some point in the future it will make more sense to do v6 than v4 and to get there we have to get more v6 out than there is now. I don't know what that point is but I suspect someone has calculated it. What I do know is that if we want to get there sooner rather than later it make sense to make it easier and not harder to get v6 allocations. Its not like were going to run out of addresses anytime soon and if my kids or grand kids have to go through a v6 to vNumber conversion that's OK with me as I wouldn't want them to get too comfortable in the jobs they have. I do get that FIB and RIB space is limited and needs to grow but grow it will. The sky has always been falling and we have always been running out of space in the global routing table. One way of getting the space we need will be changes in hardware and software, another will be getting v4 routes out of the table. One thing is for sure if the vendors don't see a need they won't find a way. I support Gary's suggestion as written. I would change it to read "if they can pay the fee make the assignment". Sure make them show how they would utilize it but don't make artificial barriers as to the number of nodes or networks except for determination of the size of the allocation. >From the perspective of the Enterprise renumbering is excruciating and is to be avoided at all costs. It doesn't matter if it is v6 or v4, it is worth paying for an allocation just so I don't have to do that. And once I don't have to worry about renumbering I am no longer married to my current ISP. This is why I can't walk to another carrier when I get crappy service. Its not the 3-6 month wait on circuits. Its the 100+ vendors and VPNs that have to be reworked to renumber around. Just to add to the discussion, when ARIN was in San Diego I asked the question about allocations as I have 4 locations and I was wondering how the allocation might work out. The answer I received was "1 /48 for each location" it wasn't "1 /48 for each 2000 computers or 200 subnets". James On Tue, Feb 17, 2015 at 1:49 PM, Gary T. Giesen wrote: > FYI to try to address Bill Herrin's concern, I amended that they be 13 sites > in a contiguous network to try to reduce the probability that there be 13 > separate announcements, although I'm not sure how enforceable such a > provision would be. > > GTG > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of David Huberman > Sent: February-17-15 3:46 PM > To: mcr at sandelman.ca; Gary T. Giesen > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please > don't me make do ULA + NAT66) > > Michael, > > Does Gary's concrete suggestion -- adding a qualifier that you can get > approved for IPv6 space if you have 13 more sites, with no other criteria -- > make sense to you? Would you support it? > > Thanks, > David > > > -----Original Message----- > From: mcr at sandelman.ca [mailto:mcr at sandelman.ca] > Sent: Tuesday, February 17, 2015 12:42 PM > To: Gary T. Giesen > Cc: David Huberman; arin-ppml at arin.net > Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please > don't me make do ULA + NAT66) > > > Gary T. Giesen wrote: > > That's obviously a consideration but I don't want to build an IPv6 > > adoption model for my customers around something quite so fuzzy where > > one customer could be approved and another be denied. I prefer > > something a little more concrete that I can point a customer to an say > > "apply under this" and it's plain to them (and ARIN) that they > qualify. > > I completely hear you. > I've argued repeatedly (back to 2007) that this BS about routing slots is > onsense, and that these kinds of policies are preventing adoption of IPv6 by > small and middle sized enterprises. > > It's just not ARIN's job to protect routing slots. > > I'm not clear if the resulting /40 will be announced at all. > If it will remain internal with IPVPN, and then, with a PI prefix from each > *local* ISP, then you have the classic Non-Connected Network. > > -- > ] Never tell me the odds! | ipv6 mesh networks > [ > ] Michael Richardson, Sandelman Software Works | network architect > [ > ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails > [ > > > > _______________________________________________ > 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 mcr at sandelman.ca Tue Feb 17 19:43:31 2015 From: mcr at sandelman.ca (Michael Richardson) Date: Tue, 17 Feb 2015 19:43:31 -0500 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) In-Reply-To: References: <013c01d04ac7$91b10830$b5131890$@giesen.me> <01b101d04ad0$c08f63a0$41ae2ae0$@giesen.me> <3625.1424205692@sandelman.ca> Message-ID: <22141.1424220211@sandelman.ca> David Huberman wrote: > Does Gary's concrete suggestion -- adding a qualifier that you can get > approved for IPv6 space if you have 13 more sites, with no other > criteria -- make sense to you? Would you support it? As a step in the right direction, yes, I would definitely support it. I don't know where the number 13 comes from, or if I have to have 13 sites today, or plans for 13 sites, or what exactly, but that's okay. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From mcr at sandelman.ca Tue Feb 17 19:46:14 2015 From: mcr at sandelman.ca (Michael Richardson) Date: Tue, 17 Feb 2015 19:46:14 -0500 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) In-Reply-To: <030601d04afb$93d59840$bb80c8c0$@giesen.me> References: <013c01d04ac7$91b10830$b5131890$@giesen.me> <01b101d04ad0$c08f63a0$41ae2ae0$@giesen.me> <3625.1424205692@sandelman.ca> <030601d04afb$93d59840$bb80c8c0$@giesen.me> Message-ID: <22689.1424220374@sandelman.ca> Gary T. Giesen wrote: > FYI to try to address Bill Herrin's concern, I amended that they be 13 > sites in a contiguous network to try to reduce the probability that > there be 13 separate announcements, although I'm not sure how > enforceable such a provision would be. I would write that there SHOULD be *a* contiguous announcement (if there is any announcement at all). We have no way to enforce or police this, and we shouldn't even try. (I don't care if there are other announcements, they will either get filtered somewhere, have some various no-export communities, etc. I just care that the enclosing /40 is announced so that the details can be filtered) -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From mwinters at edwardrose.com Wed Feb 18 08:46:30 2015 From: mwinters at edwardrose.com (Mike Winters) Date: Wed, 18 Feb 2015 13:46:30 +0000 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) In-Reply-To: <030601d04afb$93d59840$bb80c8c0$@giesen.me> References: <013c01d04ac7$91b10830$b5131890$@giesen.me> <01b101d04ad0$c08f63a0$41ae2ae0$@giesen.me> <3625.1424205692@sandelman.ca> <030601d04afb$93d59840$bb80c8c0$@giesen.me> Message-ID: Curious, how do you define a site? -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Gary T. Giesen Sent: Tuesday, February 17, 2015 4:49 PM To: 'David Huberman'; mcr at sandelman.ca Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) FYI to try to address Bill Herrin's concern, I amended that they be 13 sites in a contiguous network to try to reduce the probability that there be 13 separate announcements, although I'm not sure how enforceable such a provision would be. GTG -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Huberman Sent: February-17-15 3:46 PM To: mcr at sandelman.ca; Gary T. Giesen Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) Michael, Does Gary's concrete suggestion -- adding a qualifier that you can get approved for IPv6 space if you have 13 more sites, with no other criteria -- make sense to you? Would you support it? Thanks, David -----Original Message----- From: mcr at sandelman.ca [mailto:mcr at sandelman.ca] Sent: Tuesday, February 17, 2015 12:42 PM To: Gary T. Giesen Cc: David Huberman; arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) Gary T. Giesen wrote: > That's obviously a consideration but I don't want to build an IPv6 > adoption model for my customers around something quite so fuzzy where > one customer could be approved and another be denied. I prefer > something a little more concrete that I can point a customer to an say > "apply under this" and it's plain to them (and ARIN) that they qualify. I completely hear you. I've argued repeatedly (back to 2007) that this BS about routing slots is onsense, and that these kinds of policies are preventing adoption of IPv6 by small and middle sized enterprises. It's just not ARIN's job to protect routing slots. I'm not clear if the resulting /40 will be announced at all. If it will remain internal with IPVPN, and then, with a PI prefix from each *local* ISP, then you have the classic Non-Connected Network. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ _______________________________________________ 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 ggiesen at giesen.me Wed Feb 18 09:22:16 2015 From: ggiesen at giesen.me (Gary T. Giesen) Date: Wed, 18 Feb 2015 09:22:16 -0500 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) In-Reply-To: References: <013c01d04ac7$91b10830$b5131890$@giesen.me> <01b101d04ad0$c08f63a0$41ae2ae0$@giesen.me> <3625.1424205692@sandelman.ca> <030601d04afb$93d59840$bb80c8c0$@giesen.me> Message-ID: <03cd01d04b86$4c2fdb50$e48f91f0$@giesen.me> Don't need to. The NRPM defines a site in 2.10 ( https://www.arin.net/policy/nrpm.html#two10) -----Original Message----- From: Mike Winters [mailto:mwinters at edwardrose.com] Sent: February-18-15 8:47 AM To: Gary T. Giesen; 'David Huberman'; mcr at sandelman.ca Cc: arin-ppml at arin.net Subject: RE: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) Curious, how do you define a site? -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Gary T. Giesen Sent: Tuesday, February 17, 2015 4:49 PM To: 'David Huberman'; mcr at sandelman.ca Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) FYI to try to address Bill Herrin's concern, I amended that they be 13 sites in a contiguous network to try to reduce the probability that there be 13 separate announcements, although I'm not sure how enforceable such a provision would be. GTG -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Huberman Sent: February-17-15 3:46 PM To: mcr at sandelman.ca; Gary T. Giesen Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) Michael, Does Gary's concrete suggestion -- adding a qualifier that you can get approved for IPv6 space if you have 13 more sites, with no other criteria -- make sense to you? Would you support it? Thanks, David -----Original Message----- From: mcr at sandelman.ca [mailto:mcr at sandelman.ca] Sent: Tuesday, February 17, 2015 12:42 PM To: Gary T. Giesen Cc: David Huberman; arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) Gary T. Giesen wrote: > That's obviously a consideration but I don't want to build an IPv6 > adoption model for my customers around something quite so fuzzy where > one customer could be approved and another be denied. I prefer > something a little more concrete that I can point a customer to an say > "apply under this" and it's plain to them (and ARIN) that they qualify. I completely hear you. I've argued repeatedly (back to 2007) that this BS about routing slots is onsense, and that these kinds of policies are preventing adoption of IPv6 by small and middle sized enterprises. It's just not ARIN's job to protect routing slots. I'm not clear if the resulting /40 will be announced at all. If it will remain internal with IPVPN, and then, with a PI prefix from each *local* ISP, then you have the classic Non-Connected Network. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ _______________________________________________ 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 hvgeekwtrvl at gmail.com Wed Feb 18 11:07:14 2015 From: hvgeekwtrvl at gmail.com (james machado) Date: Wed, 18 Feb 2015 08:07:14 -0800 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) In-Reply-To: <03cd01d04b86$4c2fdb50$e48f91f0$@giesen.me> References: <013c01d04ac7$91b10830$b5131890$@giesen.me> <01b101d04ad0$c08f63a0$41ae2ae0$@giesen.me> <3625.1424205692@sandelman.ca> <030601d04afb$93d59840$bb80c8c0$@giesen.me> <03cd01d04b86$4c2fdb50$e48f91f0$@giesen.me> Message-ID: some argument to make the infrastructure/DC a site as well. On Wed, Feb 18, 2015 at 6:22 AM, Gary T. Giesen wrote: > Don't need to. The NRPM defines a site in 2.10 ( > https://www.arin.net/policy/nrpm.html#two10) > > -----Original Message----- > From: Mike Winters [mailto:mwinters at edwardrose.com] > Sent: February-18-15 8:47 AM > To: Gary T. Giesen; 'David Huberman'; mcr at sandelman.ca > Cc: arin-ppml at arin.net > Subject: RE: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please > don't me make do ULA + NAT66) > > Curious, how do you define a site? > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Gary T. Giesen > Sent: Tuesday, February 17, 2015 4:49 PM > To: 'David Huberman'; mcr at sandelman.ca > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please > don't me make do ULA + NAT66) > > FYI to try to address Bill Herrin's concern, I amended that they be 13 sites > in a contiguous network to try to reduce the probability that there be 13 > separate announcements, although I'm not sure how enforceable such a > provision would be. > > GTG > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of David Huberman > Sent: February-17-15 3:46 PM > To: mcr at sandelman.ca; Gary T. Giesen > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please > don't me make do ULA + NAT66) > > Michael, > > Does Gary's concrete suggestion -- adding a qualifier that you can get > approved for IPv6 space if you have 13 more sites, with no other criteria -- > make sense to you? Would you support it? > > Thanks, > David > > > -----Original Message----- > From: mcr at sandelman.ca [mailto:mcr at sandelman.ca] > Sent: Tuesday, February 17, 2015 12:42 PM > To: Gary T. Giesen > Cc: David Huberman; arin-ppml at arin.net > Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please > don't me make do ULA + NAT66) > > > Gary T. Giesen wrote: > > That's obviously a consideration but I don't want to build an IPv6 > > adoption model for my customers around something quite so fuzzy where > > one customer could be approved and another be denied. I prefer > > something a little more concrete that I can point a customer to an say > > "apply under this" and it's plain to them (and ARIN) that they > qualify. > > I completely hear you. > I've argued repeatedly (back to 2007) that this BS about routing slots is > onsense, and that these kinds of policies are preventing adoption of IPv6 by > small and middle sized enterprises. > > It's just not ARIN's job to protect routing slots. > > I'm not clear if the resulting /40 will be announced at all. > If it will remain internal with IPVPN, and then, with a PI prefix from each > *local* ISP, then you have the classic Non-Connected Network. > > -- > ] Never tell me the odds! | ipv6 mesh networks > [ > ] Michael Richardson, Sandelman Software Works | network architect > [ > ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails > [ > > > > _______________________________________________ > 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 ggiesen at giesen.me Wed Feb 18 11:11:29 2015 From: ggiesen at giesen.me (Gary T. Giesen) Date: Wed, 18 Feb 2015 11:11:29 -0500 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) In-Reply-To: References: <013c01d04ac7$91b10830$b5131890$@giesen.me> <01b101d04ad0$c08f63a0$41ae2ae0$@giesen.me> <023201d04ada$d5577930$80066b90$@giesen.me> Message-ID: <03f701d04b95$8e66b390$ab341ab0$@giesen.me> Bill, Does the following text: "By having a network that has at least 13 sites within one contiguous network, or;" sufficiently address your concerns about routing table slots? All, The reality is ALL IPv6 policy is around routing table slots whether we admit it or not. If we had TCAMS with trillions of slots the only policy around IPv6 would be not whether you can get a direct assignment, only the size of it. The flip side of that is if you don't allow small and midsized organizations to get direct assignments, we will get ZERO traction on IPv6. Even at the 13 site threshold, renumbering 13 sites is an ENORMOUS undertaking, especially if there are extranets involved, where coordination is difficult and you have little ability to motivate the other party. Imagine a scenario where a company has 10 VPN tunnels to suppliers, partners, etc. Imagine it takes 2 months per tunnel to renumber by the time you've gone through the change control process on both sides, etc. That could be nearly two years of fairly concerted effort, and none of those are at all unrealistic numbers. You quickly start to see the problem with businesses not being able to control their own destiny with respect to addressing. No company will accept that kind of risk. So we're left with two options. We can let everyone do ULA + NAT66 (which I hope we can agree is detrimental to the IPv6 Internet as a whole), or we give all but the very smallest of organizations the ability to get a direct assignment should they choose. GTG -----Original Message----- From: William Herrin [mailto:bill at herrin.us] Sent: February-17-15 1:06 PM To: Gary T. Giesen Cc: David Huberman; John Curran; arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) On Tue, Feb 17, 2015 at 12:54 PM, Gary T. Giesen wrote: > I don't necessarily disagree. Just trying to minimize the business > risk of having to have virtually all of my customers qualify under e) > with the risk of rejection because my use case isn't specifically spelled out. Hi Gary, When your use case is within an inch or two the one we'd like to prevent, 50 new routes in the table, each serving 10 people on average, business risk kinda goes with the territory. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From bill at herrin.us Wed Feb 18 11:43:45 2015 From: bill at herrin.us (William Herrin) Date: Wed, 18 Feb 2015 11:43:45 -0500 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) In-Reply-To: <03f701d04b95$8e66b390$ab341ab0$@giesen.me> References: <013c01d04ac7$91b10830$b5131890$@giesen.me> <01b101d04ad0$c08f63a0$41ae2ae0$@giesen.me> <023201d04ada$d5577930$80066b90$@giesen.me> <03f701d04b95$8e66b390$ab341ab0$@giesen.me> Message-ID: On Wed, Feb 18, 2015 at 11:11 AM, Gary T. Giesen wrote: > Imagine a scenario where a company has 10 VPN tunnels to suppliers, > partners, etc. Imagine it takes 2 months per tunnel to renumber by the time > you've gone through the change control process on both sides, etc. That > could be nearly two years of fairly concerted effort, and none of those are > at all unrealistic numbers. Hi Gary, Renumbering is HARD. Renumbering is EXPENSIVE. Few fools still claim otherwise. On the other hand routing slots are also expensive and fairly distributing the $10k/year systemic cost guesstimate of an IPv6 routing slot to the 40k or so organizations who are collectively compelled to spend it has proven to be an intractable problem. I worked up a BGP cost estimate half a decade ago; the numbers are out of date but you may still find it informative. The renumbering cost is not a good enough reason to increase the IPv6 table size. This is pointed out in NRPM 6.3.8: "In IPv6 address policy, the goal of aggregation is considered to be the most important." This means aggregation with your ISP's address space where technically feasible. Frankly, the solution to your problem is: buy a second ISP link at your core site that the other sites aggregate to. Even if it's just a backup link based on commodity DSL, cable or satellite plus a tunnel out to a data center-located BGP speaker. Having multihomed, aggregation with your ISP is no longer technically feasible. This has been proven over and over again. That's why it's one of the criteria that establishes justification for IPv6 direct assignments. Multihoming eliminates your business risk for not being able to get IPv6 addresses. And such a simple backup link is for sure less expensive than the renumbering cost. And as an added bonus it makes your network more reliable. ;) Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From ggiesen at giesen.me Wed Feb 18 11:47:59 2015 From: ggiesen at giesen.me (Gary T. Giesen) Date: Wed, 18 Feb 2015 11:47:59 -0500 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) In-Reply-To: References: <013c01d04ac7$91b10830$b5131890$@giesen.me> <01b101d04ad0$c08f63a0$41ae2ae0$@giesen.me> <023201d04ada$d5577930$80066b90$@giesen.me> <03f701d04b95$8e66b390$ab341ab0$@giesen.me> Message-ID: <03f901d04b9a$a748d780$f5da8680$@giesen.me> Bill, Am I to assume then that you disagree with the provisions in NRPM 6.5.8.1 c. and d. then? GTG -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin Sent: February 18, 2015 11:44 AM To: Gary T. Giesen Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) On Wed, Feb 18, 2015 at 11:11 AM, Gary T. Giesen wrote: > Imagine a scenario where a company has 10 VPN tunnels to suppliers, > partners, etc. Imagine it takes 2 months per tunnel to renumber by the > time you've gone through the change control process on both sides, > etc. That could be nearly two years of fairly concerted effort, and > none of those are at all unrealistic numbers. Hi Gary, Renumbering is HARD. Renumbering is EXPENSIVE. Few fools still claim otherwise. On the other hand routing slots are also expensive and fairly distributing the $10k/year systemic cost guesstimate of an IPv6 routing slot to the 40k or so organizations who are collectively compelled to spend it has proven to be an intractable problem. I worked up a BGP cost estimate half a decade ago; the numbers are out of date but you may still find it informative. The renumbering cost is not a good enough reason to increase the IPv6 table size. This is pointed out in NRPM 6.3.8: "In IPv6 address policy, the goal of aggregation is considered to be the most important." This means aggregation with your ISP's address space where technically feasible. Frankly, the solution to your problem is: buy a second ISP link at your core site that the other sites aggregate to. Even if it's just a backup link based on commodity DSL, cable or satellite plus a tunnel out to a data center-located BGP speaker. Having multihomed, aggregation with your ISP is no longer technically feasible. This has been proven over and over again. That's why it's one of the criteria that establishes justification for IPv6 direct assignments. Multihoming eliminates your business risk for not being able to get IPv6 addresses. And such a simple backup link is for sure less expensive than the renumbering cost. And as an added bonus it makes your network more reliable. ;) Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: _______________________________________________ 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 Wed Feb 18 12:59:47 2015 From: bill at herrin.us (William Herrin) Date: Wed, 18 Feb 2015 12:59:47 -0500 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) In-Reply-To: <03f901d04b9a$a748d780$f5da8680$@giesen.me> References: <013c01d04ac7$91b10830$b5131890$@giesen.me> <01b101d04ad0$c08f63a0$41ae2ae0$@giesen.me> <023201d04ada$d5577930$80066b90$@giesen.me> <03f701d04b95$8e66b390$ab341ab0$@giesen.me> <03f901d04b9a$a748d780$f5da8680$@giesen.me> Message-ID: On Wed, Feb 18, 2015 at 11:47 AM, Gary T. Giesen wrote: > Am I to assume then that you disagree with the provisions in NRPM 6.5.8.1 c. > and d. then? Hi Gary, Actually, I think that for now any end user willing to pay ARIN's fee should qualify for a /48 regardless of any technical criteria. The v4 swamp caused no lasting harm but the v6 deployment delay while we dance around justification has been nasty. On the other hand, I don't think such an approach should outlive the v4/v6 50/50 mark so it wouldn't resolve your long term business risk concerns. Long term I think 6.5.8.1 c and d are an artifact of our willingness to accept single homed entities in to the IPv4 table, something that made more sense two decades ago when Internet connections were sparsely available. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From SRyerse at eclipse-networks.com Wed Feb 18 13:17:16 2015 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Wed, 18 Feb 2015 18:17:16 +0000 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD120174BE2A0F@ENI-MAIL.eclipse-networks.com> I agree. I would also add that I got my IPv6 block from ARIN three years ago and have been dutifully paying the bill for it each year, even though I don't have a customer asking for IPv6 yet. I'm betting that there are a lot of orgs in this situation. Putting needs tests on IPv6 blocks is only slowing down the IPv6 transition and hurting my investment in IPv6. I vote for Gary's 2nd option "we give all but the very smallest of organizations the ability to get a direct assignment should they choose". Steven L Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA? 30338 770.656.1460 - Cell 770.399.9099 - Office 770.392-0076 - Fax ? Eclipse Networks, Inc. ??????? Conquering Complex Networks? -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Gary T. Giesen Sent: Wednesday, February 18, 2015 11:11 AM To: 'William Herrin'; arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Pleasedon't me make do ULA + NAT66) Bill, Does the following text: "By having a network that has at least 13 sites within one contiguous network, or;" sufficiently address your concerns about routing table slots? All, The reality is ALL IPv6 policy is around routing table slots whether we admit it or not. If we had TCAMS with trillions of slots the only policy around IPv6 would be not whether you can get a direct assignment, only the size of it. The flip side of that is if you don't allow small and midsized organizations to get direct assignments, we will get ZERO traction on IPv6. Even at the 13 site threshold, renumbering 13 sites is an ENORMOUS undertaking, especially if there are extranets involved, where coordination is difficult and you have little ability to motivate the other party. Imagine a scenario where a company has 10 VPN tunnels to suppliers, partners, etc. Imagine it takes 2 months per tunnel to renumber by the time you've gone through the change control process on both sides, etc. That could be nearly two years of fairly concerted effort, and none of those are at all unrealistic numbers. You quickly start to see the problem with businesses not being able to control their own destiny with respect to addressing. No company will accept that kind of risk. So we're left with two options. We can let everyone do ULA + NAT66 (which I hope we can agree is detrimental to the IPv6 Internet as a whole), or we give all but the very smallest of organizations the ability to get a direct assignment should they choose. GTG -----Original Message----- From: William Herrin [mailto:bill at herrin.us] Sent: February-17-15 1:06 PM To: Gary T. Giesen Cc: David Huberman; John Curran; arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) On Tue, Feb 17, 2015 at 12:54 PM, Gary T. Giesen wrote: > I don't necessarily disagree. Just trying to minimize the business > risk of having to have virtually all of my customers qualify under e) > with the risk of rejection because my use case isn't specifically > spelled out. Hi Gary, When your use case is within an inch or two the one we'd like to prevent, 50 new routes in the table, each serving 10 people on average, business risk kinda goes with the territory. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: _______________________________________________ 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 Wed Feb 18 16:28:55 2015 From: bill at herrin.us (William Herrin) Date: Wed, 18 Feb 2015 16:28:55 -0500 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) In-Reply-To: References: <013c01d04ac7$91b10830$b5131890$@giesen.me> <01b101d04ad0$c08f63a0$41ae2ae0$@giesen.me> <023201d04ada$d5577930$80066b90$@giesen.me> <03f701d04b95$8e66b390$ab341ab0$@giesen.me> <03f901d04b9a$a748d780$f5da8680$@giesen.me> Message-ID: On Wed, Feb 18, 2015 at 12:59 PM, William Herrin wrote: > I think that for now any end user willing to pay ARIN's fee > should qualify for a /48 regardless of any technical criteria. This got me thinking. Who would choke on a policy proposal which looked like the following? Add to section 6.5.8.1: (f) All end user organizations who do not qualify for addresses under (a) through (e) qualify for a direct assignment of exactly one /48. This section (f) shall expire upon determination by ARIN staff that IPv6 has become the "dominant" network protocol on the public Internet. The expiry shall not impact prior assignments made under this section. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From hvgeekwtrvl at gmail.com Wed Feb 18 17:47:15 2015 From: hvgeekwtrvl at gmail.com (james machado) Date: Wed, 18 Feb 2015 14:47:15 -0800 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) In-Reply-To: References: <013c01d04ac7$91b10830$b5131890$@giesen.me> <01b101d04ad0$c08f63a0$41ae2ae0$@giesen.me> <023201d04ada$d5577930$80066b90$@giesen.me> <03f701d04b95$8e66b390$ab341ab0$@giesen.me> <03f901d04b9a$a748d780$f5da8680$@giesen.me> Message-ID: So we argue for a /48 for each home user site but we toss out that argument when it comes to a smaller business with multiple sites? I applaud the intent but think it is too short sighted William. It should take no more routing slots for an aggregated /40 or /44 than for a /48 and the /40 or /44 are in line with the v6 paradigm that has been fronted on this list and others. On Wed, Feb 18, 2015 at 1:28 PM, William Herrin wrote: > On Wed, Feb 18, 2015 at 12:59 PM, William Herrin wrote: >> I think that for now any end user willing to pay ARIN's fee >> should qualify for a /48 regardless of any technical criteria. > > This got me thinking. Who would choke on a policy proposal which > looked like the following? > > Add to section 6.5.8.1: > > (f) All end user organizations who do not qualify for addresses under > (a) through (e) qualify for a direct assignment of exactly one /48. > This section (f) shall expire upon determination by ARIN staff that > IPv6 has become the "dominant" network protocol on the public > Internet. The expiry shall not impact prior assignments made under > this section. > > Regards, > Bill Herrin > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: > _______________________________________________ > 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 tknow.com Wed Feb 18 17:59:02 2015 From: bill at tknow.com (Bill Buhler) Date: Wed, 18 Feb 2015 22:59:02 +0000 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) In-Reply-To: References: <013c01d04ac7$91b10830$b5131890$@giesen.me> <01b101d04ad0$c08f63a0$41ae2ae0$@giesen.me> <023201d04ada$d5577930$80066b90$@giesen.me> <03f701d04b95$8e66b390$ab341ab0$@giesen.me> <03f901d04b9a$a748d780$f5da8680$@giesen.me> Message-ID: <6997bc437e6941c48e7d04a98b4b7ab8@TK-Ex13.ad.tknow.com> I second that, I fail to see the harm in allowing any company that qualifies for a direct ipv6 be allocated a /40. There are many companies in the US that would never use up all 256 internal /48s, and there are some that would need more, or want to perhaps move the site mask to a /56, but with an automatic initial assignment of that size it would be easy to justify as a future proof allocation to the executive team. It also seems to me that entities larger than this are more likely to have multiple AS numbers and be using multiple routing slots anyway so multiple blocks might make more sense... Best regards, Bill Buhler -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of james machado Sent: Wednesday, February 18, 2015 3:47 PM To: William Herrin Cc: Gary T. Giesen; arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) So we argue for a /48 for each home user site but we toss out that argument when it comes to a smaller business with multiple sites? I applaud the intent but think it is too short sighted William. It should take no more routing slots for an aggregated /40 or /44 than for a /48 and the /40 or /44 are in line with the v6 paradigm that has been fronted on this list and others. On Wed, Feb 18, 2015 at 1:28 PM, William Herrin wrote: > On Wed, Feb 18, 2015 at 12:59 PM, William Herrin wrote: >> I think that for now any end user willing to pay ARIN's fee should >> qualify for a /48 regardless of any technical criteria. > > This got me thinking. Who would choke on a policy proposal which > looked like the following? > > Add to section 6.5.8.1: > > (f) All end user organizations who do not qualify for addresses under > (a) through (e) qualify for a direct assignment of exactly one /48. > This section (f) shall expire upon determination by ARIN staff that > IPv6 has become the "dominant" network protocol on the public > Internet. The expiry shall not impact prior assignments made under > this section. > > Regards, > Bill Herrin > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: > _______________________________________________ > 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 ggiesen at giesen.me Wed Feb 18 18:02:21 2015 From: ggiesen at giesen.me (Gary T. Giesen) Date: Wed, 18 Feb 2015 18:02:21 -0500 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) In-Reply-To: References: <013c01d04ac7$91b10830$b5131890$@giesen.me> <01b101d04ad0$c08f63a0$41ae2ae0$@giesen.me> <023201d04ada$d5577930$80066b90$@giesen.me> <03f701d04b95$8e66b390$ab341ab0$@giesen.me> <03f901d04b9a$a748d780$f5da8680$@giesen.me> Message-ID: <048b01d04bce$f3b9f160$db2dd420$@giesen.me> That would not cover the particular segment of end users that I'm targeting. However, I may be convinced (although I am not yet) to support: (a) through (e) qualify for a direct assignment of a /48 per site. This section (f) shall expire upon determination by ARIN staff that IPv6 has become the "dominant" network protocol on the public Internet. The expiry shall not impact prior assignments made under this section. Although I think you'll have problems around delineating when IPv6 is the "dominant" protocol. While I don't think that time will come for a very long time, I think people will still cry foul when that decree comes. GTG -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin Sent: February 18, 2015 4:29 PM To: Gary T. Giesen Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) On Wed, Feb 18, 2015 at 12:59 PM, William Herrin wrote: > I think that for now any end user willing to pay ARIN's fee should > qualify for a /48 regardless of any technical criteria. This got me thinking. Who would choke on a policy proposal which looked like the following? Add to section 6.5.8.1: (f) All end user organizations who do not qualify for addresses under (a) through (e) qualify for a direct assignment of exactly one /48. This section (f) shall expire upon determination by ARIN staff that IPv6 has become the "dominant" network protocol on the public Internet. The expiry shall not impact prior assignments made under this section. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: _______________________________________________ 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 ggiesen at giesen.me Wed Feb 18 18:06:32 2015 From: ggiesen at giesen.me (Gary T. Giesen) Date: Wed, 18 Feb 2015 18:06:32 -0500 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) In-Reply-To: <6997bc437e6941c48e7d04a98b4b7ab8@TK-Ex13.ad.tknow.com> References: <013c01d04ac7$91b10830$b5131890$@giesen.me> <01b101d04ad0$c08f63a0$41ae2ae0$@giesen.me> <023201d04ada$d5577930$80066b90$@giesen.me> <03f701d04b95$8e66b390$ab341ab0$@giesen.me> <03f901d04b9a$a748d780$f5da8680$@giesen.me> <6997bc437e6941c48e7d04a98b4b7ab8@TK-Ex13.ad.tknow.com> Message-ID: <048d01d04bcf$89891400$9c9b3c00$@giesen.me> I'd argue that everyone that qualifies for more than a /48 be allocated a /40 merely on the basis of internal aggregateability. A /44 is pretty hard to have any sort of hierarchy in your address scheme if you have multiple locations nationally. And like you said, the routing slot for a /40 costs the same as for a /44. GTG -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Bill Buhler Sent: February 18, 2015 5:59 PM To: james machado; William Herrin Cc: Gary T. Giesen; arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) I second that, I fail to see the harm in allowing any company that qualifies for a direct ipv6 be allocated a /40. There are many companies in the US that would never use up all 256 internal /48s, and there are some that would need more, or want to perhaps move the site mask to a /56, but with an automatic initial assignment of that size it would be easy to justify as a future proof allocation to the executive team. It also seems to me that entities larger than this are more likely to have multiple AS numbers and be using multiple routing slots anyway so multiple blocks might make more sense... Best regards, Bill Buhler -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of james machado Sent: Wednesday, February 18, 2015 3:47 PM To: William Herrin Cc: Gary T. Giesen; arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) So we argue for a /48 for each home user site but we toss out that argument when it comes to a smaller business with multiple sites? I applaud the intent but think it is too short sighted William. It should take no more routing slots for an aggregated /40 or /44 than for a /48 and the /40 or /44 are in line with the v6 paradigm that has been fronted on this list and others. On Wed, Feb 18, 2015 at 1:28 PM, William Herrin wrote: > On Wed, Feb 18, 2015 at 12:59 PM, William Herrin wrote: >> I think that for now any end user willing to pay ARIN's fee should >> qualify for a /48 regardless of any technical criteria. > > This got me thinking. Who would choke on a policy proposal which > looked like the following? > > Add to section 6.5.8.1: > > (f) All end user organizations who do not qualify for addresses under > (a) through (e) qualify for a direct assignment of exactly one /48. > This section (f) shall expire upon determination by ARIN staff that > IPv6 has become the "dominant" network protocol on the public > Internet. The expiry shall not impact prior assignments made under > this section. > > Regards, > Bill Herrin > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: > _______________________________________________ > 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 Wed Feb 18 18:07:10 2015 From: bill at herrin.us (William Herrin) Date: Wed, 18 Feb 2015 18:07:10 -0500 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) In-Reply-To: References: <013c01d04ac7$91b10830$b5131890$@giesen.me> <01b101d04ad0$c08f63a0$41ae2ae0$@giesen.me> <023201d04ada$d5577930$80066b90$@giesen.me> <03f701d04b95$8e66b390$ab341ab0$@giesen.me> <03f901d04b9a$a748d780$f5da8680$@giesen.me> Message-ID: On Wed, Feb 18, 2015 at 5:47 PM, james machado wrote: > So we argue for a /48 for each home user site but we toss out that > argument when it comes to a smaller business with multiple sites? Hi James, I'm not sure how you get that from what I wrote below. Would you mind explaining? > On Wed, Feb 18, 2015 at 1:28 PM, William Herrin wrote: >> Add to section 6.5.8.1: >> >> (f) All end user organizations who do not qualify for addresses under >> (a) through (e) qualify for a direct assignment of exactly one /48. >> This section (f) shall expire upon determination by ARIN staff that >> IPv6 has become the "dominant" network protocol on the public >> Internet. The expiry shall not impact prior assignments made under >> this section. Also a quick nit -- top posting can make public conversation threads like this very hard to follow. I'd encourage you to comment in-line if you can. Thanks, Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From ggiesen at giesen.me Wed Feb 18 18:11:34 2015 From: ggiesen at giesen.me (Gary T. Giesen) Date: Wed, 18 Feb 2015 18:11:34 -0500 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) In-Reply-To: References: <013c01d04ac7$91b10830$b5131890$@giesen.me> <01b101d04ad0$c08f63a0$41ae2ae0$@giesen.me> <023201d04ada$d5577930$80066b90$@giesen.me> <03f701d04b95$8e66b390$ab341ab0$@giesen.me> <03f901d04b9a$a748d780$f5da8680$@giesen.me> Message-ID: <048f01d04bd0$3da74ec0$b8f5ec40$@giesen.me> Bill that's how I read it too... A single /48 for the entire end-user, not per end-user site. GTG -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin Sent: February 18, 2015 6:07 PM To: james machado Cc: Gary T. Giesen; arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) On Wed, Feb 18, 2015 at 5:47 PM, james machado wrote: > So we argue for a /48 for each home user site but we toss out that > argument when it comes to a smaller business with multiple sites? Hi James, I'm not sure how you get that from what I wrote below. Would you mind explaining? > On Wed, Feb 18, 2015 at 1:28 PM, William Herrin wrote: >> Add to section 6.5.8.1: >> >> (f) All end user organizations who do not qualify for addresses under >> (a) through (e) qualify for a direct assignment of exactly one /48. >> This section (f) shall expire upon determination by ARIN staff that >> IPv6 has become the "dominant" network protocol on the public >> Internet. The expiry shall not impact prior assignments made under >> this section. Also a quick nit -- top posting can make public conversation threads like this very hard to follow. I'd encourage you to comment in-line if you can. Thanks, Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: _______________________________________________ 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 athompso at athompso.net Wed Feb 18 18:14:32 2015 From: athompso at athompso.net (Adam Thompson) Date: Wed, 18 Feb 2015 17:14:32 -0600 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) In-Reply-To: References: <013c01d04ac7$91b10830$b5131890$@giesen.me> <01b101d04ad0$c08f63a0$41ae2ae0$@giesen.me> <023201d04ada$d5577930$80066b90$@giesen.me> <03f701d04b95$8e66b390$ab341ab0$@giesen.me> <03f901d04b9a$a748d780$f5da8680$@giesen.me> Message-ID: <54E51CD8.6060209@athompso.net> On 2015-02-18 04:47 PM, james machado wrote: > So we argue for a /48 for each home user site but we toss out that > argument when it comes to a smaller business with multiple sites? > > I applaud the intent but think it is too short sighted William. It > should take no more routing slots for an aggregated /40 or /44 than > for a /48 and the /40 or /44 are in line with the v6 paradigm that has > been fronted on this list and others. Given the high demand for IPv6 allocations (*ahem*), the minimum requirement could easily be eliminated altogether, with relatively little impact AT THIS TIME as far as I can see. I think having to justify anything larger than a /48 is reasonable, otherwise we probably would get people asking for /8s just to camp on them. I fully agree with the OP's point that not being able to get PI space represents a business risk, and that business (i.e. 2nd-order financial) risk does not scale in any way an engineer or scientist would expect. I have one regional ISP customer who could probably renumber in two weeks with relatively little impact, whereas I have one large (Fortune 500-sized, but private) multinational enterprise customer who could be in danger of bankruptcy if they lost one single IPv4 /24. My point here is that there *is* business risk, sometimes enormous risk, tied to using non-PI space. As technologists we find this next bit uncomfortable: there's no formula to predict the level of risk. This makes writing policy to address it very difficult, but writing policy that ignores it is worse. I've been using the multi-homed clause for all the non-SP customers I work with, so far, since none of them have enough public IP resources to warrant a direct allocation otherwise. Even in the mid-western Canada telecom wasteland, it's almost always possible to get two connections... even if one is a tiny local ISP who doesn't even run BGP or IPv6 themselves, that still satisfies (IIRC) the letter of the NRPM. (Besides, then there's a reason for that tiny local ISP to improve rapidly.) This is, unsurprisingly, why I was very unhappy to see the multi-homed clause vanish from the IPv4 section. -- -Adam Thompson athompso at athompso.net +1 (204) 291-7950 - cell +1 (204) 489-6515 - fax From hvgeekwtrvl at gmail.com Wed Feb 18 18:54:27 2015 From: hvgeekwtrvl at gmail.com (james machado) Date: Wed, 18 Feb 2015 15:54:27 -0800 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) In-Reply-To: References: <013c01d04ac7$91b10830$b5131890$@giesen.me> <01b101d04ad0$c08f63a0$41ae2ae0$@giesen.me> <023201d04ada$d5577930$80066b90$@giesen.me> <03f701d04b95$8e66b390$ab341ab0$@giesen.me> <03f901d04b9a$a748d780$f5da8680$@giesen.me> Message-ID: On Wed, Feb 18, 2015 at 3:07 PM, William Herrin wrote: > On Wed, Feb 18, 2015 at 5:47 PM, james machado wrote: >> So we argue for a /48 for each home user site but we toss out that >> argument when it comes to a smaller business with multiple sites? > > Hi James, > > I'm not sure how you get that from what I wrote below. Would you mind > explaining? > HI Bill, Sorry about the top posting, I'll claim laziness and email client making it too easy to top post. For example a business with 2 up-streams but only one supports v6 at this time and the customer doesn't qualify for their own v4 assignment. Business has more than 1 site but less than 10 and is starting to roll v6 out. Say the sites are 50 devices in total so were looking at between 50 and 500 devices with smtp but onsite website. For v4 they have a supplied /24 which is why they still have one provider who doesn't supply v6 because as soon as they change they have to renumber. This business does not qualify for a direct v6 assignment under (a) through (e) as I currently read them and due to v4 NAT wouldn't qualify for a direct v4 assignment. They are already have the problem of renumbering for v4 and if they accept a v6 allocation from their upstream now have 2 renumbering scenarios to deal with in the future. OK lets give them a /48 per (f)(wh) and they can put v6 in place but are they doing it correctly? Nope they are splitting their /48 across multiple sites and will again have to re-number when and if they get a larger assignment. Additionally now that we are advocating /48 assignments to endpoints with multiple sites we might as well start giving out /60's to end users to "save addresses". I am not saying that there are not times when a /48 might be the correct initial assignment what I am saying is that I think the initial assignment should be based on site count but the barrier for entry should be lower than it is. The game is rigged toward the ISPs and that is not all bad but whats going to drive v6 adoption is not ISPs, it's going to be business small and large and Johnny who got a for the holidays but can't who are going to drive v6 adoption. For the "Enterprise" customers there are other issues with v6 that don't concern ISPs that are their own headache but don't let address scarcity add to that. James > >> On Wed, Feb 18, 2015 at 1:28 PM, William Herrin wrote: >>> Add to section 6.5.8.1: >>> >>> (f) All end user organizations who do not qualify for addresses under >>> (a) through (e) qualify for a direct assignment of exactly one /48. >>> This section (f) shall expire upon determination by ARIN staff that >>> IPv6 has become the "dominant" network protocol on the public >>> Internet. The expiry shall not impact prior assignments made under >>> this section. > > Also a quick nit -- top posting can make public conversation threads > like this very hard to follow. I'd encourage you to comment in-line if > you can. > > Thanks, > Bill > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: From owen at delong.com Thu Feb 19 00:08:38 2015 From: owen at delong.com (Owen DeLong) Date: Wed, 18 Feb 2015 21:08:38 -0800 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) In-Reply-To: References: <013c01d04ac7$91b10830$b5131890$@giesen.me> <01b101d04ad0$c08f63a0$41ae2ae0$@giesen.me> <023201d04ada$d5577930$80066b90$@giesen.me> <03f701d04b95$8e66b390$ab341ab0$@giesen.me> <03f901d04b9a$a748d780$f5da8680$@giesen.me> Message-ID: <84CEB86B-FB0C-41BC-A585-A6248BDB4ABB@delong.com> I would oppose such a proposal. It?s convoluted, the sunset is unpredictable at best and the artificial limitation or one /48 regardless of the number of sites is, IMHO, absurd. You can?t claim defense of the routing table, because a /48 and a /32 occupy the same number of routing slots. Owen > On Feb 18, 2015, at 1:28 PM, William Herrin wrote: > > On Wed, Feb 18, 2015 at 12:59 PM, William Herrin wrote: >> I think that for now any end user willing to pay ARIN's fee >> should qualify for a /48 regardless of any technical criteria. > > This got me thinking. Who would choke on a policy proposal which > looked like the following? > > Add to section 6.5.8.1: > > (f) All end user organizations who do not qualify for addresses under > (a) through (e) qualify for a direct assignment of exactly one /48. > This section (f) shall expire upon determination by ARIN staff that > IPv6 has become the "dominant" network protocol on the public > Internet. The expiry shall not impact prior assignments made under > this section. > > Regards, > Bill Herrin > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: > _______________________________________________ > 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 narten at us.ibm.com Fri Feb 20 00:53:03 2015 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 20 Feb 2015 00:53:03 -0500 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201502200553.t1K5r3hT007747@rotala.raleigh.ibm.com> Total of 45 messages in the last 7 days. script run at: Fri Feb 20 00:53:03 EST 2015 Messages | Bytes | Who --------+------+--------+----------+------------------------ 37.78% | 17 | 39.19% | 228360 | ggiesen at giesen.me 11.11% | 5 | 19.22% | 112000 | david.huberman at microsoft.com 13.33% | 6 | 7.10% | 41372 | bill at herrin.us 6.67% | 3 | 9.40% | 54795 | sryerse at eclipse-networks.com 8.89% | 4 | 6.72% | 39174 | hvgeekwtrvl at gmail.com 6.67% | 3 | 3.22% | 18777 | mcr at sandelman.ca 2.22% | 1 | 6.44% | 37536 | woody at pch.net 2.22% | 1 | 1.73% | 10097 | jcurran at arin.net 2.22% | 1 | 1.64% | 9558 | bill at tknow.com 2.22% | 1 | 1.47% | 8590 | mwinters at edwardrose.com 2.22% | 1 | 1.39% | 8128 | athompso at athompso.net 2.22% | 1 | 1.35% | 7846 | owen at delong.com 2.22% | 1 | 1.11% | 6470 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 45 |100.00% | 582703 | Total From rjletts at uw.edu Fri Feb 20 14:12:36 2015 From: rjletts at uw.edu (Richard J. Letts) Date: Fri, 20 Feb 2015 19:12:36 +0000 Subject: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66) In-Reply-To: References: <013c01d04ac7$91b10830$b5131890$@giesen.me> <01b101d04ad0$c08f63a0$41ae2ae0$@giesen.me> <023201d04ada$d5577930$80066b90$@giesen.me> <03f701d04b95$8e66b390$ab341ab0$@giesen.me> <03f901d04b9a$a748d780$f5da8680$@giesen.me> Message-ID: I have read the scenarios people have presented and I have not understood what the problem statement is. Has anyone asked and failed to get IPv6 resources? It looks to me like the problem statements are for really small businesses and caused by poor network design, or the assumption that having *both* ULA and global IPv6 addresses on the same host is going to be a problem. e.g. why not use ULA internally on a network for internal resources, use provider-based RA assignments for external connectivity. Then you only have to manage site-to-site VPN connections for the ULA networks. Switching external providers is a matter of updating router configs (adding new subnets to interfaces), and reconfiguring the site<>site VPN tunnels (all of which should be in the same engineering management domain), and NOT reconfiguring 126 hosts. [business with 62-126 or more IPv4 addresses should be able to obtain at least one /24 of public IPv4 space and then apply for IPv6 space under 6.5.8.1(a)] If you've a vendor<>customer VPN connection then that's a specific technical challenge -- I have several of these and they are *all* engineered differently and break in their own unique ways. I don't think it's possible to write a generic policy that covers what's needed to get these to work except 6.5.8.1(e) would appear to me to be the policy to apply for space under. Has anyone failed to get space under that section? Having justified the initial assignment criteria the initial assignment size is independent and the business should get sufficient space to cover the number of sites under 6.5.8.2 Like I said, I feel I'm not understanding if this is a real problem where businesses have actually been denied IPv6 address space? Richard Letts From ms258322 at gmail.com Tue Feb 24 05:34:07 2015 From: ms258322 at gmail.com (Mike Smith) Date: Tue, 24 Feb 2015 19:34:07 +0900 Subject: [arin-ppml] incorrect database info cause routing issue Message-ID: Hi Following block has been assgined to Afrinic however it still shows ARIN block in the db. 45.160.0.0-45.255.255.255. Please check it and correct it. regards. mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo.vegoda at icann.org Tue Feb 24 11:17:53 2015 From: leo.vegoda at icann.org (Leo Vegoda) Date: Tue, 24 Feb 2015 16:17:53 +0000 Subject: [arin-ppml] incorrect database info cause routing issue In-Reply-To: References: Message-ID: <78a1fca4754546b795d52a2ba7b75ac9@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> Mike Smith wrote: [...] > Following block has been assgined to Afrinic however it still shows > ARIN block in the db. > > 45.160.0.0-45.255.255.255. > > Please check it and correct it. 45.160.0.0 - 45.191.255.255 was allocated to LACNIC in May last year (https://www.iana.org/assignments/ipv4-recovered-address-space/ipv4-recovered-address-space.xhtml#ipv4-recovered-address-space-2) and ARIN's whois server redirects to LACNIC's when queried for addresses in that range: $ whois -h whois.arin.net 45.160.0.0 [Querying whois.arin.net] [Redirected to whois.lacnic.net] [Querying whois.lacnic.net] [whois.lacnic.net] % Joint Whois - whois.lacnic.net % This server accepts single ASN, IPv4 or IPv6 queries It is only the second half of the 45.160.0.0 - 45.255.255.255 that is allocated to AFRINIC. Regards, Leo Vegoda -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5475 bytes Desc: not available URL: From info at arin.net Tue Feb 24 12:17:13 2015 From: info at arin.net (ARIN) Date: Tue, 24 Feb 2015 12:17:13 -0500 Subject: [arin-ppml] Draft Policy ARIN-2014-14: Needs Attestation for some IPv4 Transfers - Revised Message-ID: <54ECB219.7030707@arin.net> ARIN-2014-14 has been revised. This draft policy is open for discussion on this mailing list. ARIN-2014-14 is below and can be found at: https://www.arin.net/policy/proposals/2014_14.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy ARIN-2014-14 Needs Attestation for some IPv4 Transfers Date: 24 Feb 2015 Problem Statement: The process of 'needs testing' or 'needs basis' allocation has evolved over the history of the Internet registry system. The earliest number resource policy required that an operator intend to use the number resources on an operational Internet Protocol network before the resource would be registered to an organization. Organizations were assigned either a Class A, B, or C block roughly depending on the organization's size. With the implementation of CIDR, additional 'needs testing' was done to right size allocations to fit organizations. These testing requirements continued to evolve under various organizations prior to the RIRs inception and then later formally under the RIR's policy development process. In the 2000s, ARIN began a systematic "trust but verify" process for IPv4 requests. This was necessary due to both IPv4 address registration hijackings in ARIN Whois and the accelerated amount of systematic fraud being perpetrated on ARIN. As IPv4 exhaustion occurred, some RIRs have reconsidered the necessity of some of the needs testing requirements and implemented policies which reduced the requirements on organizations to show need or utilization for some transfer transactions with the RIR. The cost of performing a needs assessment and auditing of this information vs. the public benefit of restricting allocations to specifically qualified organizations has been noted by some organizations to be out of alignment. The ability to predict future use toward a 24-month utilization rate can also be challenging for some organizations and relies on projections and estimates rather than verifiable facts. Thus, the current needs testing requirements may be more than is necessary and desirable for small transfers. This policy seeks to reduce the complexity of transfers by removing the utilization needs testing requirement and replacing it with a needs attestation by a corporate officer. Additionally, other requirements are placed around the 'needs attestation only' requirement to reduce the Number Resource Community's concern that this type of policy could be abused for speculation or hording. Furthermore, the policy includes a sunset clause to limit the total number of transfers under this policy proposal. This sunset is intended to force the community to reexamine the success or failure of the practices contained in this policy proposal. Policy statement: Section 8.3 Replace the 'Conditions on recipient of the transfer' with the following conditions. Conditions on recipient of the transfer: The organization must sign an RSA. The resources transferred will be subject to current ARIN policies. In addition, the recipient must meet one of the following requirements sets: 1. The organization must demonstrate the need for up to a 24-month supply of IP address resources under current ARIN policies. OR 1.The organization, its parent(s), or subsidiary organizations, must not have received IPv4 address resources, via transfer, within the past 12 months. 2.An officer of the organization must attest that the IPv4 address block is needed for and will be used on an operational network. 3.The maximum transfer size is /20. 4.Fewer than 5,000 needs attestation transfers have occurred. Section 8.4 Replace the 'Conditions on recipient of the transfer' with the following conditions. Conditions on recipient of the transfer: The conditions on a recipient outside of the ARIN region will be defined by the policies of the receiving RIR. Recipients within the ARIN region will be subject to current ARIN policies and sign an RSA for the resources being received. The minimum transfer size is a /24. In addition, the recipient must meet one of the following requirements sets: 1. The organization must demonstrate the need for up to a 24-month supply of IP address resources under current ARIN policies. OR 1.The organization, its parent(s), or subsidiary organizations, must not have received IPv4 address resources, via transfer, within the past 12 months. 2.An officer of the organization must attest that the IPv4 address block is needed for and will be used on an operational network. 3.The maximum transfer size is /20. 4.Fewer than 5,000 needs attestation transfers have occurred. Comments: Timetable for implementation: Immediate From info at arin.net Tue Feb 24 12:52:30 2015 From: info at arin.net (ARIN) Date: Tue, 24 Feb 2015 12:52:30 -0500 Subject: [arin-ppml] =?windows-1252?q?NRPM_2015=2E1_=96_New_Policy_Impleme?= =?windows-1252?q?nted_=28ARIN-2014-9=29?= Message-ID: <54ECBA5E.7070508@arin.net> On 12 January 2015 the ARIN Board of Trustees adopted the following number policy: ARIN-2014-9: Resolve Conflict Between RSA and 8.2 Utilization Requirements https://www.arin.net/policy/proposals/2014_9.html This policy removed the words "aggregate" and "reclaim" from NRPM Section 8.2: Mergers and Acquisitions. A new version of the ARIN Number Resource Policy Manual (NRPM) has been published to the ARIN website. NRPM version 2015.1 is effective 24 February 2015 and supersedes the previous version. The NRPM is available at: https://www.arin.net/policy/nrpm.html Board minutes are available at: https://www.arin.net/about_us/bot/index.html Draft policies and proposals are available at: https://www.arin.net/policy/proposals/ The ARIN Policy Development Process is available at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Tue Feb 24 12:54:19 2015 From: info at arin.net (ARIN) Date: Tue, 24 Feb 2015 12:54:19 -0500 Subject: [arin-ppml] Advisory Council Meeting Results - February 2015 Message-ID: <54ECBACB.4010102@arin.net> In accordance with the ARIN Policy Development Process (PDP), the ARIN Advisory Council (AC) met on 19 February 2015. The AC moved the following to last call (to be posted separately to last call): Recommended Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate The AC abandoned the following: Recommended Draft Policy ARIN-2014-19: New MDN Allocation Based on Past Utilization The AC provided the following statement: "The ARIN AC abandoned Recommended Draft Policy ARIN-2014-19: New MDN Allocation Based on Past Utilization. In the process of investigating and working on this policy the AC discovered that ARIN staff practice is already consistent with the language in this policy proposal, and as a result this policy would not change current ARIN staff practice. In particular, if an MDN has a 1 year utilization history then it is not a new MDN and would be treated as an existing MDN. The AC has noted, however, that some clarification of the MDN policy and current staff procedures is needed in the NRPM, and has requested that ARIN staff update online documentation to clarify existing staff practice around MDN policy." The AC is continuing to work on: Recommended Draft Policy ARIN-2014-1: Out of Region Use Draft Policy ARIN-2014-6: Remove Operational Reverse DNS Text Draft Policy ARIN-2014-14: Removing Needs Test from Small IPv4 Transfers Draft Policy ARIN-2014-21: Modification to CI Pool Size per Section 4.4 Draft Policy ARIN-2014-22: Removal of Minimum in Section 4.10 The AC abandoned 2014-19. Anyone dissatisfied with this decision may initiate a petition. The deadline to begin a petition will be five business days after the AC's draft meeting minutes are published. For more information on starting and participating in petitions, see PDP Petitions at: https://www.arin.net/policy/pdp_petitions.html Draft Policy and Proposal texts are available at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Tue Feb 24 12:55:53 2015 From: info at arin.net (ARIN) Date: Tue, 24 Feb 2015 12:55:53 -0500 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate Message-ID: <54ECBB29.4030103@arin.net> The ARIN Advisory Council (AC) met on 19 February 2015 and decided to send the following to last call: Recommended Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate Feedback is encouraged during the last call period. All comments should be provided to the Public Policy Mailing List. This last call will expire on 10 March 2015. After last call the AC will conduct their last call review. The draft policy text is below and available at: https://www.arin.net/policy/proposals/ The ARIN Policy Development Process is available at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Recommended Draft Policy ARIN-2014-17 Change Utilization Requirements from last-allocation to total-aggregate Date: 19 October 2014 AC's assessment of conformance with the Principles of Internet Number Resource Policy: This proposal enables fair and impartial number resource administration by removing an impediment to additional allocations seen by some organizations due to the shortening of the assignment window to three months and the gradual reduction of minimum block size over the past 5 years. This draft proposal applies equally to all organizations and now requires that any netblock show at least 50% utilization before an additional block can be allocated or assigned. The policy is clear and implementable as written. This proposal is technically sound. There are no technical issues which are raised by changing the utilization definition within the NRPM. This proposal is supported by the community. Support for this draft proposal has been growing as it has been discussed. Additional support from the community was seen as issues which were brought to the attention of the community by the first staff and legal assessment have been mitigated. Problem Statement: Current ARIN policy calculates utilization on a per allocation basis rather than in aggregate. This method of determining utilization may cause some organizations to be unable to qualify for additional address blocks despite attempting to use their resource allocations as best as possible. This issue has been exacerbated in the past couple of years due to the 3-month allocation window which causes organizations to receive smaller non-expandable allocations rather than a larger aggregate. For example, if an organization has 4 x /22 and 3 of them are utilized 100% and the fourth utilized at 75%, an additional allocation request would be denied. However, an organization with a single /20 utilized at 80% would have less efficient utilization but would be eligible to receive additional space. Policy statement: Replace Section 4.2.4.1 ISPs must have efficiently utilized all allocations, in aggregate, to at least 80% and at least 50% of every allocation in order to receive additional space. This includes all space reassigned to their customers. Replace Section 4.3.6.1 End-users must have efficiently utilized all assignments, in aggregate, to at least 80% and at least 50% of every assignment in order to receive additional space, and must provide ARIN with utilization details. Timetable for implementation: Immediate ##### ARIN STAFF ASSESSMENT Draft Policy ARIN-2014-17 Change Utilization Requirements from last-allocation to total-aggregate Date of Assessment: November 2014 1. Summary (Staff Understanding) This policy removes the current requirement to have efficiently utilized all previous allocations and assignments, and 80% of the most recent one, and replaces it with the requirement to have efficiently utilized all allocations and assignments in aggregate, to at least 80% overall, with at least a 50% utilization of every allocated or assigned block. 2. Comments A. ARIN Staff Comments Based on staff experience, the 80% utilization rate of the last block has been periodically problematic for smaller ISPs, but not for medium to larger ISPs. Staff has seen situations where a small ISP with a /22 may need to issue a /24 to a customer but not have any available, not be at 80% utilized, and therefore, not be able to request additional space. This policy could be implemented as written. B. ARIN General Counsel - Legal Assessment The policy does not present material legal issues. Allocation rules to address concerns of small ISP's indicate ARIN's continued attempts to balance the needs of stewardship with the needs of different sectors. 3. Resource Impact This policy would have minimal resource impact from an implementation aspect. 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 and internal procedures -Staff training 4. Proposal/Draft Policy Text Assessed Draft Policy ARIN-2014-17 Change Utilization Requirements from last-allocation to total-aggregate Date: 19 October 2014 Problem Statement: Current ARIN policy calculates utilization on a per allocation basis rather than in aggregate. This method of determining utilization may cause some organizations to be unable to qualify for additional address blocks despite attempting to use their resource allocations as best as possible. This issue has been exacerbated in the past couple of years due to the 3-month allocation window which causes organizations to receive smaller non-expandable allocations rather than a larger aggregate. For example, if an organization has 4 x /22 and 3 of them are utilized 100% and the fourth utilized at 75%, an additional allocation request would be denied. However, an organization with a single /20 utilized at 80% would have less efficient utilization but would be eligible to receive additional space. Policy statement: Replace Section 4.2.4.1 ISPs must have efficiently utilized all allocations, in aggregate, to at least 80% and at least 50% of every allocation in order to receive additional space. This includes all space reassigned to their customers. Replace Section 4.3.6.1 End-users must have efficiently utilized all assignments, in aggregate, to at least 80% and at least 50% of every assignment in order to receive additional space, and must provide ARIN with utilization details. From info at arin.net Tue Feb 24 12:58:22 2015 From: info at arin.net (ARIN) Date: Tue, 24 Feb 2015 12:58:22 -0500 Subject: [arin-ppml] NRPM Section 5 - Notice of intent to make editorial update Message-ID: <54ECBBBE.9080402@arin.net> The ARIN Advisory Council (AC) met on 19 February 2015 and requested that the following proposed editorial update to the Number Resource Policy Manual (NRPM) be posted for review by the community. NRPM Section 5. AS Numbers Current text regarding numbers for private use: Sites that do not require a unique AS Number should use one or more of the AS Numbers reserved for private use. Those numbers are: 64512 through 65535. Proposed correction: Sites that do not require a unique AS Number should use one or more of the AS Numbers reserved for private use. Those numbers are: 64512 through 65534 and 4200000000 through 4294967294 inclusive. For reference, links the the RFCs in question. https://tools.ietf.org/html/rfc6996 https://tools.ietf.org/html/rfc7300 Between the two RFCs the status of 65535 has been clarified and a new much larger range of 32-bit AS Numbers has been added to the Private-Use AS Number Range. The process for editorial updates to the NRPM is found in Part One, Section 3.1, paragraph 3 of the PDP: "Changes to policy that are purely editorial and non-substantial in nature are outside the scope of the full Policy Development Process and may only be made with 30 days public notice followed by the concurrence of both the ARIN Advisory Council and ARIN Board of Trustees that the changes are non-substantial in nature." Your feedback on this issue is appreciated. The review period will close on 27 March 2015. The Number Resource Policy Manual is available at: https://www.arin.net/policy/nrpm.html#five The ARIN Policy Development Process is available at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From owen at delong.com Tue Feb 24 15:04:42 2015 From: owen at delong.com (Owen DeLong) Date: Tue, 24 Feb 2015 12:04:42 -0800 Subject: [arin-ppml] Draft Policy ARIN-2014-14: Needs Attestation for some IPv4 Transfers - Revised In-Reply-To: <54ECB219.7030707@arin.net> References: <54ECB219.7030707@arin.net> Message-ID: I do not oppose the policy as written. I?m not sure I support it, but if we want to conduct such an experiment, then I believe this policy provides adequate protections and limitations on the scope of the experiment. Owen > On Feb 24, 2015, at 09:17 , ARIN wrote: > > ARIN-2014-14 has been revised. This draft policy is open for discussion > on this mailing list. > > ARIN-2014-14 is below and can be found at: > https://www.arin.net/policy/proposals/2014_14.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Draft Policy ARIN-2014-14 > Needs Attestation for some IPv4 Transfers > > Date: 24 Feb 2015 > > Problem Statement: > > The process of 'needs testing' or 'needs basis' allocation has evolved > over the history of the Internet registry system. The earliest number > resource policy required that an operator intend to use the number > resources on an operational Internet Protocol network before the > resource would be registered to an organization. Organizations were > assigned either a Class A, B, or C block roughly depending on the > organization's size. With the implementation of CIDR, additional 'needs > testing' was done to right size allocations to fit organizations. These > testing requirements continued to evolve under various organizations > prior to the RIRs inception and then later formally under the RIR's > policy development process. > > In the 2000s, ARIN began a systematic "trust but verify" process for > IPv4 requests. This was necessary due to both IPv4 address registration > hijackings in ARIN Whois and the accelerated amount of systematic fraud > being perpetrated on ARIN. > > As IPv4 exhaustion occurred, some RIRs have reconsidered the necessity > of some of the needs testing requirements and implemented policies > which reduced the requirements on organizations to show need or > utilization for some transfer transactions with the RIR. > > The cost of performing a needs assessment and auditing of this > information vs. the public benefit of restricting allocations to > specifically qualified organizations has been noted by some > organizations to be out of alignment. The ability to predict future use > toward a 24-month utilization rate can also be challenging for some > organizations and relies on projections and estimates rather than > verifiable facts. Thus, the current needs testing requirements may be > more than is necessary and desirable for small transfers. This policy > seeks to reduce the complexity of transfers by removing the utilization > needs testing requirement and replacing it with a needs attestation by > a corporate officer. > > Additionally, other requirements are placed around the 'needs > attestation only' requirement to reduce the Number Resource Community's > concern that this type of policy could be abused for speculation or > hording. Furthermore, the policy includes a sunset clause to limit the > total number of transfers under this policy proposal. This sunset is > intended to force the community to reexamine the success or failure of > the practices contained in this policy proposal. > > Policy statement: > > Section 8.3 > > Replace the 'Conditions on recipient of the transfer' with > the following conditions. > > Conditions on recipient of the transfer: > > The organization must sign an RSA. > > The resources transferred will be subject to current ARIN policies. > > In addition, the recipient must meet one of the following requirements > sets: > > 1. The organization must demonstrate the need for up to a 24-month > supply of IP address resources under current ARIN policies. > > OR > > 1.The organization, its parent(s), or subsidiary organizations, must > not have received IPv4 address resources, via transfer, within the past 12 months. > > 2.An officer of the organization must attest that the IPv4 address > block is needed for and will be used on an operational network. > > 3.The maximum transfer size is /20. > > 4.Fewer than 5,000 needs attestation transfers have occurred. > > > Section 8.4 > > Replace the 'Conditions on recipient of the transfer' with > the following conditions. > > Conditions on recipient of the transfer: > > The conditions on a recipient outside of the ARIN region will be > defined by the policies of the receiving RIR. > > Recipients within the ARIN region will be subject to current ARIN > policies and sign an RSA for the resources being received. > > The minimum transfer size is a /24. > > In addition, the recipient must meet one of the following requirements > sets: > > 1. The organization must demonstrate the need for up to a 24-month > supply of IP address resources under current ARIN policies. > > OR > > 1.The organization, its parent(s), or subsidiary organizations, must > not have received IPv4 address resources, via transfer, within the past 12 months. > > 2.An officer of the organization must attest that the IPv4 address > block is needed for and will be used on an operational network. > > 3.The maximum transfer size is /20. > > 4.Fewer than 5,000 needs attestation transfers have occurred. > > Comments: > > Timetable for implementation: Immediate > _______________________________________________ > 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 athompso at athompso.net Tue Feb 24 15:32:07 2015 From: athompso at athompso.net (Adam Thompson) Date: Tue, 24 Feb 2015 14:32:07 -0600 Subject: [arin-ppml] Draft Policy ARIN-2014-14: Needs Attestation for some IPv4 Transfers - Revised In-Reply-To: References: <54ECB219.7030707@arin.net> Message-ID: <3164C2BB-0E5A-4723-A08D-FE100E6FB146@athompso.net> Based on "the perfect is the enemy of the good", I figure it's worth going ahead with this. If it turns out to be a disaster, the policy can be revised in... what's the minimum, 6 months? And there are ways to mitigate its impact during that time if necessary. Much as mentioned in the policy statement, we're working with estimates and guesses, not verifiable facts. This will at least generate some verifiable facts. I'm equally certain it will need revision/tweaking at some point fairly soon. -Adam On February 24, 2015 2:04:42 PM CST, Owen DeLong wrote: >I do not oppose the policy as written. I?m not sure I support it, but >if we want to conduct such an experiment, then I believe this policy >provides adequate protections and limitations on the scope of the >experiment. > >Owen > >> On Feb 24, 2015, at 09:17 , ARIN wrote: >> >> ARIN-2014-14 has been revised. This draft policy is open for >discussion >> on this mailing list. >> >> ARIN-2014-14 is below and can be found at: >> https://www.arin.net/policy/proposals/2014_14.html >> >> Regards, >> >> Communications and Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ## * ## >> >> >> Draft Policy ARIN-2014-14 >> Needs Attestation for some IPv4 Transfers >> >> Date: 24 Feb 2015 >> >> Problem Statement: >> >> The process of 'needs testing' or 'needs basis' allocation has >evolved >> over the history of the Internet registry system. The earliest number >> resource policy required that an operator intend to use the number >> resources on an operational Internet Protocol network before the >> resource would be registered to an organization. Organizations were >> assigned either a Class A, B, or C block roughly depending on the >> organization's size. With the implementation of CIDR, additional >'needs >> testing' was done to right size allocations to fit organizations. >These >> testing requirements continued to evolve under various organizations >> prior to the RIRs inception and then later formally under the RIR's >> policy development process. >> >> In the 2000s, ARIN began a systematic "trust but verify" process for >> IPv4 requests. This was necessary due to both IPv4 address >registration >> hijackings in ARIN Whois and the accelerated amount of systematic >fraud >> being perpetrated on ARIN. >> >> As IPv4 exhaustion occurred, some RIRs have reconsidered the >necessity >> of some of the needs testing requirements and implemented policies >> which reduced the requirements on organizations to show need or >> utilization for some transfer transactions with the RIR. >> >> The cost of performing a needs assessment and auditing of this >> information vs. the public benefit of restricting allocations to >> specifically qualified organizations has been noted by some >> organizations to be out of alignment. The ability to predict future >use >> toward a 24-month utilization rate can also be challenging for some >> organizations and relies on projections and estimates rather than >> verifiable facts. Thus, the current needs testing requirements may be >> more than is necessary and desirable for small transfers. This policy >> seeks to reduce the complexity of transfers by removing the >utilization >> needs testing requirement and replacing it with a needs attestation >by >> a corporate officer. >> >> Additionally, other requirements are placed around the 'needs >> attestation only' requirement to reduce the Number Resource >Community's >> concern that this type of policy could be abused for speculation or >> hording. Furthermore, the policy includes a sunset clause to limit >the >> total number of transfers under this policy proposal. This sunset is >> intended to force the community to reexamine the success or failure >of >> the practices contained in this policy proposal. >> >> Policy statement: >> >> Section 8.3 >> >> Replace the 'Conditions on recipient of the transfer' with >> the following conditions. >> >> Conditions on recipient of the transfer: >> >> The organization must sign an RSA. >> >> The resources transferred will be subject to current ARIN policies. >> >> In addition, the recipient must meet one of the following >requirements >> sets: >> >> 1. The organization must demonstrate the need for up to a 24-month >> supply of IP address resources under current ARIN policies. >> >> OR >> >> 1.The organization, its parent(s), or subsidiary organizations, must >> not have received IPv4 address resources, via transfer, within the >past 12 months. >> >> 2.An officer of the organization must attest that the IPv4 address >> block is needed for and will be used on an operational network. >> >> 3.The maximum transfer size is /20. >> >> 4.Fewer than 5,000 needs attestation transfers have occurred. >> >> >> Section 8.4 >> >> Replace the 'Conditions on recipient of the transfer' with >> the following conditions. >> >> Conditions on recipient of the transfer: >> >> The conditions on a recipient outside of the ARIN region will be >> defined by the policies of the receiving RIR. >> >> Recipients within the ARIN region will be subject to current ARIN >> policies and sign an RSA for the resources being received. >> >> The minimum transfer size is a /24. >> >> In addition, the recipient must meet one of the following >requirements >> sets: >> >> 1. The organization must demonstrate the need for up to a 24-month >> supply of IP address resources under current ARIN policies. >> >> OR >> >> 1.The organization, its parent(s), or subsidiary organizations, must >> not have received IPv4 address resources, via transfer, within the >past 12 months. >> >> 2.An officer of the organization must attest that the IPv4 address >> block is needed for and will be used on an operational network. >> >> 3.The maximum transfer size is /20. >> >> 4.Fewer than 5,000 needs attestation transfers have occurred. >> >> Comments: >> >> Timetable for implementation: Immediate >> _______________________________________________ >> 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. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.buhrmaster at gmail.com Tue Feb 24 15:55:06 2015 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Tue, 24 Feb 2015 20:55:06 +0000 Subject: [arin-ppml] Draft Policy ARIN-2014-14: Needs Attestation for some IPv4 Transfers - Revised In-Reply-To: <54ECB219.7030707@arin.net> References: <54ECB219.7030707@arin.net> Message-ID: On Tue, Feb 24, 2015 at 5:17 PM, ARIN wrote: > ARIN-2014-14 has been revised. This draft policy is open for discussion > on this mailing list. .... > Draft Policy ARIN-2014-14 > Needs Attestation for some IPv4 Transfers Trying to better understand the details..... > 2.An officer of the organization must attest that the IPv4 address > block is needed for and will be used on an operational network. So no time frame at all for usage in their organization? Any time frame is OK? Any organization is OK? .... > 4.Fewer than 5,000 needs attestation transfers have occurred. Where did the 5000 come from? WAG? If I calculated this correctly, that would mean somewhere between a /12 and a /8 could fall under attestation only. From andrew.dul at quark.net Tue Feb 24 17:55:52 2015 From: andrew.dul at quark.net (Andrew Dul) Date: Tue, 24 Feb 2015 14:55:52 -0800 Subject: [arin-ppml] Draft Policy ARIN-2014-14: Needs Attestation for some IPv4 Transfers - Revised In-Reply-To: References: <54ECB219.7030707@arin.net> Message-ID: <54ED0178.8010706@quark.net> On 2/24/2015 12:55 PM, Gary Buhrmaster wrote: > On Tue, Feb 24, 2015 at 5:17 PM, ARIN wrote: >> ARIN-2014-14 has been revised. This draft policy is open for discussion >> on this mailing list. > .... >> Draft Policy ARIN-2014-14 >> Needs Attestation for some IPv4 Transfers > Trying to better understand the details..... > >> 2.An officer of the organization must attest that the IPv4 address >> block is needed for and will be used on an operational network. > So no time frame at all for usage in their organization? > Any time frame is OK? Any organization is OK? I believe based upon the current text, the answers to these 3 questions is "yes." > > .... >> 4.Fewer than 5,000 needs attestation transfers have occurred. > Where did the 5000 come from? WAG? If I calculated > this correctly, that would mean somewhere between a > /12 and a /8 could fall under attestation only. It is basically a WAG. Originally on the AC list 10,000 was proposed. Why 10,000? On average over the past 5 years, ARIN has made about 2,000 allocations or assignments per year. Some members of the AC noted a smaller number was needed, and thus the next draft reduced it to 5,000. Do you support this number? If not, is there a number you would be more comfortable with? Thanks, Andrew From ms258322 at gmail.com Tue Feb 24 21:00:48 2015 From: ms258322 at gmail.com (Mike Smith) Date: Wed, 25 Feb 2015 11:00:48 +0900 Subject: [arin-ppml] incorrect database info cause routing issue In-Reply-To: <78a1fca4754546b795d52a2ba7b75ac9@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> References: <78a1fca4754546b795d52a2ba7b75ac9@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> Message-ID: Hi The second half in ARIN DB shows incorrect detail. And ARIN DB claim 45/8 is managed by ARIN. On Wednesday, February 25, 2015, Leo Vegoda wrote: > Mike Smith wrote: > > [...] > > > Following block has been assgined to Afrinic however it still shows > > ARIN block in the db. > > > > 45.160.0.0-45.255.255.255. > > > > Please check it and correct it. > > 45.160.0.0 - 45.191.255.255 was allocated to LACNIC in May last year > ( > https://www.iana.org/assignments/ipv4-recovered-address-space/ipv4-recovered-address-space.xhtml#ipv4-recovered-address-space-2 > ) > and ARIN's whois server redirects to LACNIC's when queried for addresses in > that range: > > $ whois -h whois.arin.net 45.160.0.0 > [Querying whois.arin.net] > [Redirected to whois.lacnic.net] > [Querying whois.lacnic.net] > [whois.lacnic.net] > > % Joint Whois - whois.lacnic.net > % This server accepts single ASN, IPv4 or IPv6 queries > > It is only the second half of the 45.160.0.0 - 45.255.255.255 that is > allocated to AFRINIC. > > Regards, > > Leo Vegoda > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ms258322 at gmail.com Tue Feb 24 21:04:49 2015 From: ms258322 at gmail.com (Mike Smith) Date: Wed, 25 Feb 2015 11:04:49 +0900 Subject: [arin-ppml] incorrect database info cause routing issue In-Reply-To: References: <78a1fca4754546b795d52a2ba7b75ac9@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> Message-ID: Can anyone from ARIN correct such obvious error. On Wednesday, February 25, 2015, Mike Smith wrote: > Hi > > The second half in ARIN DB shows incorrect detail. > > And ARIN DB claim 45/8 is managed by ARIN. > > On Wednesday, February 25, 2015, Leo Vegoda > wrote: > >> Mike Smith wrote: >> >> [...] >> >> > Following block has been assgined to Afrinic however it still shows >> > ARIN block in the db. >> > >> > 45.160.0.0-45.255.255.255. >> > >> > Please check it and correct it. >> >> 45.160.0.0 - 45.191.255.255 was allocated to LACNIC in May last year >> ( >> https://www.iana.org/assignments/ipv4-recovered-address-space/ipv4-recovered-address-space.xhtml#ipv4-recovered-address-space-2 >> ) >> and ARIN's whois server redirects to LACNIC's when queried for addresses >> in >> that range: >> >> $ whois -h whois.arin.net 45.160.0.0 >> [Querying whois.arin.net] >> [Redirected to whois.lacnic.net] >> [Querying whois.lacnic.net] >> [whois.lacnic.net] >> >> % Joint Whois - whois.lacnic.net >> % This server accepts single ASN, IPv4 or IPv6 queries >> >> It is only the second half of the 45.160.0.0 - 45.255.255.255 that is >> allocated to AFRINIC. >> >> Regards, >> >> Leo Vegoda >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cja at daydream.com Tue Feb 24 21:15:24 2015 From: cja at daydream.com (CJ Aronson) Date: Tue, 24 Feb 2015 19:15:24 -0700 Subject: [arin-ppml] incorrect database info cause routing issue In-Reply-To: References: <78a1fca4754546b795d52a2ba7b75ac9@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> Message-ID: This is a public policy mailing list. If you want to contact ARIN you may have better results by using their Contact US info https://www.arin.net/contact_us.html Just a thought. -----Cathy {?,?} (( )) ? ? On Tue, Feb 24, 2015 at 7:04 PM, Mike Smith wrote: > Can anyone from ARIN correct such obvious error. > > > On Wednesday, February 25, 2015, Mike Smith wrote: > >> Hi >> >> The second half in ARIN DB shows incorrect detail. >> >> And ARIN DB claim 45/8 is managed by ARIN. >> >> On Wednesday, February 25, 2015, Leo Vegoda wrote: >> >>> Mike Smith wrote: >>> >>> [...] >>> >>> > Following block has been assgined to Afrinic however it still shows >>> > ARIN block in the db. >>> > >>> > 45.160.0.0-45.255.255.255. >>> > >>> > Please check it and correct it. >>> >>> 45.160.0.0 - 45.191.255.255 was allocated to LACNIC in May last year >>> ( >>> https://www.iana.org/assignments/ipv4-recovered-address-space/ipv4-recovered-address-space.xhtml#ipv4-recovered-address-space-2 >>> ) >>> and ARIN's whois server redirects to LACNIC's when queried for addresses >>> in >>> that range: >>> >>> $ whois -h whois.arin.net 45.160.0.0 >>> [Querying whois.arin.net] >>> [Redirected to whois.lacnic.net] >>> [Querying whois.lacnic.net] >>> [whois.lacnic.net] >>> >>> % Joint Whois - whois.lacnic.net >>> % This server accepts single ASN, IPv4 or IPv6 queries >>> >>> It is only the second half of the 45.160.0.0 - 45.255.255.255 that is >>> allocated to AFRINIC. >>> >>> Regards, >>> >>> Leo Vegoda >>> >> > _______________________________________________ > 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 ms258322 at gmail.com Tue Feb 24 21:55:14 2015 From: ms258322 at gmail.com (Mike Smith) Date: Wed, 25 Feb 2015 11:55:14 +0900 Subject: [arin-ppml] incorrect database info cause routing issue In-Reply-To: References: <78a1fca4754546b795d52a2ba7b75ac9@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> Message-ID: Hi I have sent them an email and seems no reply. Can any one from Arin clarify how to report their DB inconsistency? On Wednesday, February 25, 2015, CJ Aronson wrote: > This is a public policy mailing list. If you want to contact ARIN you may > have better results by using their Contact US info > > https://www.arin.net/contact_us.html > > Just a thought. > > -----Cathy > > > {?,?} > (( )) > ? ? > > On Tue, Feb 24, 2015 at 7:04 PM, Mike Smith > wrote: > >> Can anyone from ARIN correct such obvious error. >> >> >> On Wednesday, February 25, 2015, Mike Smith > > wrote: >> >>> Hi >>> >>> The second half in ARIN DB shows incorrect detail. >>> >>> And ARIN DB claim 45/8 is managed by ARIN. >>> >>> On Wednesday, February 25, 2015, Leo Vegoda >>> wrote: >>> >>>> Mike Smith wrote: >>>> >>>> [...] >>>> >>>> > Following block has been assgined to Afrinic however it still shows >>>> > ARIN block in the db. >>>> > >>>> > 45.160.0.0-45.255.255.255. >>>> > >>>> > Please check it and correct it. >>>> >>>> 45.160.0.0 - 45.191.255.255 was allocated to LACNIC in May last year >>>> ( >>>> https://www.iana.org/assignments/ipv4-recovered-address-space/ipv4-recovered-address-space.xhtml#ipv4-recovered-address-space-2 >>>> ) >>>> and ARIN's whois server redirects to LACNIC's when queried for >>>> addresses in >>>> that range: >>>> >>>> $ whois -h whois.arin.net 45.160.0.0 >>>> [Querying whois.arin.net] >>>> [Redirected to whois.lacnic.net] >>>> [Querying whois.lacnic.net] >>>> [whois.lacnic.net] >>>> >>>> % Joint Whois - whois.lacnic.net >>>> % This server accepts single ASN, IPv4 or IPv6 queries >>>> >>>> It is only the second half of the 45.160.0.0 - 45.255.255.255 that is >>>> allocated to AFRINIC. >>>> >>>> Regards, >>>> >>>> Leo Vegoda >>>> >>> >> _______________________________________________ >> 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 christopher.morrow at gmail.com Wed Feb 25 02:48:19 2015 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Wed, 25 Feb 2015 00:48:19 -0700 Subject: [arin-ppml] incorrect database info cause routing issue In-Reply-To: References: <78a1fca4754546b795d52a2ba7b75ac9@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> Message-ID: On Tue, Feb 24, 2015 at 7:55 PM, Mike Smith wrote: > Hi > > I have sent them an email and seems no reply. Can any one from Arin clarify > how to report their DB inconsistency? you mailed hostmaster at arin.net and got a ticket response, correct? that ticket should be how you track your problem to successful conclusion. > > > On Wednesday, February 25, 2015, CJ Aronson wrote: >> >> This is a public policy mailing list. If you want to contact ARIN you may >> have better results by using their Contact US info >> >> https://www.arin.net/contact_us.html >> >> Just a thought. >> >> -----Cathy >> >> >> {?,?} >> (( )) >> ? ? >> >> On Tue, Feb 24, 2015 at 7:04 PM, Mike Smith wrote: >>> >>> Can anyone from ARIN correct such obvious error. >>> >>> >>> On Wednesday, February 25, 2015, Mike Smith wrote: >>>> >>>> Hi >>>> >>>> The second half in ARIN DB shows incorrect detail. >>>> >>>> And ARIN DB claim 45/8 is managed by ARIN. >>>> >>>> On Wednesday, February 25, 2015, Leo Vegoda >>>> wrote: >>>>> >>>>> Mike Smith wrote: >>>>> >>>>> [...] >>>>> >>>>> > Following block has been assgined to Afrinic however it still shows >>>>> > ARIN block in the db. >>>>> > >>>>> > 45.160.0.0-45.255.255.255. >>>>> > >>>>> > Please check it and correct it. >>>>> >>>>> 45.160.0.0 - 45.191.255.255 was allocated to LACNIC in May last year >>>>> >>>>> (https://www.iana.org/assignments/ipv4-recovered-address-space/ipv4-recovered-address-space.xhtml#ipv4-recovered-address-space-2) >>>>> and ARIN's whois server redirects to LACNIC's when queried for >>>>> addresses in >>>>> that range: >>>>> >>>>> $ whois -h whois.arin.net 45.160.0.0 >>>>> [Querying whois.arin.net] >>>>> [Redirected to whois.lacnic.net] >>>>> [Querying whois.lacnic.net] >>>>> [whois.lacnic.net] >>>>> >>>>> % Joint Whois - whois.lacnic.net >>>>> % This server accepts single ASN, IPv4 or IPv6 queries >>>>> >>>>> It is only the second half of the 45.160.0.0 - 45.255.255.255 that is >>>>> allocated to AFRINIC. >>>>> >>>>> Regards, >>>>> >>>>> Leo Vegoda >>> >>> >>> _______________________________________________ >>> 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 jcurran at arin.net Wed Feb 25 06:50:31 2015 From: jcurran at arin.net (John Curran) Date: Wed, 25 Feb 2015 11:50:31 +0000 Subject: [arin-ppml] incorrect database info cause routing issue In-Reply-To: References: <78a1fca4754546b795d52a2ba7b75ac9@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> Message-ID: <65445B8D-65C0-4231-9DE4-2A0A58541BD6@corp.arin.net> Mike - Please email hostmaster at arin.net if you believe there to be an inconsistency in the ARIN Whois database. Please be as precise as possible regarding the entries that you are concerned about, and we will research and respond directly. Thanks! /John John Curran President and CEO ARIN On Feb 24, 2015, at 9:55 PM, Mike Smith > wrote: Hi I have sent them an email and seems no reply. Can any one from Arin clarify how to report their DB inconsistency? On Wednesday, February 25, 2015, CJ Aronson > wrote: This is a public policy mailing list. If you want to contact ARIN you may have better results by using their Contact US info https://www.arin.net/contact_us.html Just a thought. -----Cathy {?,?} (( )) ? ? On Tue, Feb 24, 2015 at 7:04 PM, Mike Smith > wrote: Can anyone from ARIN correct such obvious error. On Wednesday, February 25, 2015, Mike Smith > wrote: Hi The second half in ARIN DB shows incorrect detail. And ARIN DB claim 45/8 is managed by ARIN. On Wednesday, February 25, 2015, Leo Vegoda wrote: Mike Smith wrote: [...] > Following block has been assgined to Afrinic however it still shows > ARIN block in the db. > > 45.160.0.0-45.255.255.255. > > Please check it and correct it. 45.160.0.0 - 45.191.255.255 was allocated to LACNIC in May last year (https://www.iana.org/assignments/ipv4-recovered-address-space/ipv4-recovered-address-space.xhtml#ipv4-recovered-address-space-2) and ARIN's whois server redirects to LACNIC's when queried for addresses in that range: $ whois -h whois.arin.net 45.160.0.0 [Querying whois.arin.net] [Redirected to whois.lacnic.net] [Querying whois.lacnic.net] [whois.lacnic.net] % Joint Whois - whois.lacnic.net % This server accepts single ASN, IPv4 or IPv6 queries It is only the second half of the 45.160.0.0 - 45.255.255.255 that is allocated to AFRINIC. Regards, Leo Vegoda _______________________________________________ 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 jlewis at lewis.org Wed Feb 25 13:10:03 2015 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 25 Feb 2015 13:10:03 -0500 (EST) Subject: [arin-ppml] 2014-1 Out of Region Use In-Reply-To: References: <91f996151ef44b03b2179e253c0af1db@EX13-MBX-13.ad.syr.edu> <5447331D.9040009@ipinc.net> <4cbf6e7c109641259f86835fc5435cce@EX13-MBX-13.ad.syr.edu> Message-ID: On Wed, 22 Oct 2014, Martin Hannigan wrote: >>> resources stating that this is a no op as well: already using numbers in >>> other regions and even ARIN (Curran) chimed in and said that it wasn't >>> a problem. >> >> I think you're interpretation of the situation is WAY out of line with >> the reality. Staff wants to STOP out of region use, and is doing so de >> facto because of the ambiguities in the policy. Yes, lots of people are >> already using numbers in other regions but if you want to continue to >> do that with new requests we need to solidify the policy and make it >> clear that this is ok. >> > > I don't think I took the discussion out of context at all. Both Matt > Petach and I stood up and said that we both use numbers out of region. > What's the big deal? John commented that it wasn't. If that's not > accurate, I'd be interested in your interpretation. Sorry about digging up this old thread... The problem (my problem anyway) is that I was just told by ARIN staff (Leslie Nobile at the event yesterday and confirmed just now via the helpdesk) that NRPM 4.5 can't be used by an ARIN member to request resources to be used out of region and, perhaps more troubling, that v4 space used out of region does not count towards calculating space utilization when an organization requests additional space from ARIN unless a less specific route is advertised in-region. I wasn't prepared to argue about either of these "policies" yesterday, but after searching the NRPM, I can't find any basis for either of them. So, I called the helpdesk to double-check / ask where in the NRPM I could find these "policies". I was told they're based on ARIN's interpretation of 2.2, specifically "The primary role of RIRs is to manage and distribute public Internet address space within their respective regions." Those are some very specific "policies" derived from a very vague sentence, which I think could just as reasonably be interpreted as meaning the RIRs exist to serve organizations headquartered in their respective service regions. You're a US corporation, ARIN is your RIR. You're a German corporation, RIPE is your RIR. >> "The requirement to have a minimal level of resources deployed in the >> region (/44 for IPv6, /22 for IPv4, 1 ASN) is an attempt to respond to >> law enforcement and some community concerns. An absolute threshold >> ensures that those applying for ARIN resources are actually operating >> in the region and not simply a shell company, but it avoids the known >> pitfalls of trying to use percentages of the organization's overall >> holdings to do that." I think I understand the intent of that requirement, but it's kind of pointless, especially as currently written: ARIN registered resources may be used outside the ARIN service region. Out of region use of IPv4, IPv6, or ASNs are valid justification for additional number resources if the applicant is currently using at least the equivalent of a /22 of IPv4, /44 of IPv6, or 1 ASN within the ARIN service region, respectively. If I were a European org wanting to get space from ARIN instead of RIPE, all I have to do is buy a VM on some ARIN-region cloud provider, get them to do BGP with my VM, and I've satisfied the requirement? If you think that's far fetched, see the recent thread on NANOG about cloud providers willing to do BGP with VMs. All that does is slightly increase the cost of violating the intent of the policy. I think 2014-1 shouldn't be necessary, but since current ARIN "policy" is based on an interpretation I disagree with of vague language in section 2, I suppose I'm all for passage of 2014-1. I just hope it doesn't have the sort of unintended consequences I think it could easily have. Does the helpdesk have many staffers who speak Romanian? ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jcurran at arin.net Wed Feb 25 13:46:18 2015 From: jcurran at arin.net (John Curran) Date: Wed, 25 Feb 2015 18:46:18 +0000 Subject: [arin-ppml] 2014-1 Out of Region Use In-Reply-To: References: <91f996151ef44b03b2179e253c0af1db@EX13-MBX-13.ad.syr.edu> <5447331D.9040009@ipinc.net> <4cbf6e7c109641259f86835fc5435cce@EX13-MBX-13.ad.syr.edu> Message-ID: <177BA06F-36D5-490B-8ADD-EC37F86708BA@corp.arin.net> On Feb 25, 2015, at 1:10 PM, Jon Lewis wrote: > > I wasn't prepared to argue about either of these "policies" yesterday, but after searching the NRPM, I can't find any basis for either of them. So, I called the helpdesk to double-check / ask where in the NRPM I could find these "policies". I was told they're based on ARIN's interpretation of 2.2, specifically "The primary role of RIRs is to manage and distribute public Internet address space within their respective regions." Jon - You probably want to reference the Policy and Experience report where we pointed out the conflict with regards to ARIN's mission and current policy text. It was at the ARIN 31 meeting in Barbados, and you can find the slides here - > Those are some very specific "policies" derived from a very vague sentence, which I think could just as reasonably be interpreted as meaning the RIRs exist to serve organizations headquartered in their respective service regions. You're a US corporation, ARIN is your RIR. You're a German corporation, RIPE is your RIR. That seems to be a very logical policy option; you might want to submit it as policy proposal. There was some past work in that direction, but the particular proposal discussed did not achieve sufficient consensus to move forward. > I think 2014-1 shouldn't be necessary, but since current ARIN "policy" is based on an interpretation I disagree with of vague language in section 2, I suppose I'm all for passage of 2014-1. Indeed - clarity in policy text is generally beneficial. > I just hope it doesn't have the sort of unintended consequences I think it could easily have. Does the helpdesk have many staffers who speak Romanian? Excellent question. The staff and legal review for 2014-1 also points out the possibility for these sorts of risks, since (if adopted) there would be real potential for serving organizations with an in-region presence that are predominantly headquartered and operational elsewhere. Thanks! /John John Curran President and CEO ARIN From stephen at sprunk.org Wed Feb 25 16:36:57 2015 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 25 Feb 2015 15:36:57 -0600 Subject: [arin-ppml] 2014-1 Out of Region Use In-Reply-To: References: <91f996151ef44b03b2179e253c0af1db@EX13-MBX-13.ad.syr.edu> <5447331D.9040009@ipinc.net> <4cbf6e7c109641259f86835fc5435cce@EX13-MBX-13.ad.syr.edu> Message-ID: <54EE4079.9060202@sprunk.org> On 25-Feb-15 12:10, Jon Lewis wrote: > I wasn't prepared to argue about either of these "policies" > yesterday, but after searching the NRPM, I can't find any basis for > either of them. So, I called the helpdesk to double-check / ask > where in the NRPM I could find these "policies". I was told they're > based on ARIN's interpretation of 2.2, specifically "The primary role > of RIRs is to manage and distribute public Internet address space > within their respective regions." I think this matches the intent of 2.2 at the time it was written: preventing "registry shopping" by registrants. > Those are some very specific "policies" derived from a very vague > sentence, Well, that's the downside to giving staff vague policies; we do so because we trust them to interpret the intent correctly and apply it to all sorts of cases we hadn't considered, but it's inevitable that their interpretation (with the best of intentions) doesn't match our intent, or that our intent changes and their interpretation doesn't. > which I think could just as reasonably be interpreted as meaning the RIRs exist to serve > organizations headquartered in their respective service regions. > You're a US corporation, ARIN is your RIR. You're a German > corporation, RIPE is your RIR. So, if I'm a German corporation and I don't like RIPE's rules, I simply set up a shell corporation in the US and get my addresses from ARIN, then use them in Germany anyway? That doesn't sound right. Such registry shopping will inevitably result in a "race to the bottom" and defeat the entire rationale for having regional registries. IMHO, addresses should come from the registry for the region in which they're used, with exceptions for "incidental" use, e.g. out-of-region usage is smaller than would justify the respective region's minimum direct allocation/assignment size. I _think_ this is what staff has been implementing all along, and I never said anything because I agreed, but if we need explicit policy to defend that interpretation, I'll write the proposal and see who else agrees. 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 -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2394 bytes Desc: S/MIME Cryptographic Signature URL: From mueller at syr.edu Wed Feb 25 16:43:18 2015 From: mueller at syr.edu (Milton L Mueller) Date: Wed, 25 Feb 2015 21:43:18 +0000 Subject: [arin-ppml] 2014-1 Out of Region Use In-Reply-To: References: <91f996151ef44b03b2179e253c0af1db@EX13-MBX-13.ad.syr.edu> <5447331D.9040009@ipinc.net> <4cbf6e7c109641259f86835fc5435cce@EX13-MBX-13.ad.syr.edu> Message-ID: Jon Yes, it's clear that you support the intent of 2014-1, which is to reconcile actual staff practice with an approved policy. But it also sounds like you think our threshold requirement can be gamed? The "speaking Romanian" issue (or more likely, speaking Chinese) has been the subject of fierce debates. Do you have specific suggestions for how we could fix this? --MM > -----Original Message----- > From: Jon Lewis [mailto:jlewis at lewis.org] > Sent: Wednesday, February 25, 2015 1:10 PM > To: Martin Hannigan > Cc: Milton L Mueller; arin-ppml at arin.net > Subject: Re: [arin-ppml] 2014-1 Out of Region Use > > On Wed, 22 Oct 2014, Martin Hannigan wrote: > > >>> resources stating that this is a no op as well: already using > >>> numbers in other regions and even ARIN (Curran) chimed in and said > >>> that it wasn't a problem. > >> > >> I think you're interpretation of the situation is WAY out of line > >> with the reality. Staff wants to STOP out of region use, and is doing > >> so de facto because of the ambiguities in the policy. Yes, lots of > >> people are already using numbers in other regions but if you want to > >> continue to do that with new requests we need to solidify the policy > >> and make it clear that this is ok. > >> > > > > I don't think I took the discussion out of context at all. Both Matt > > Petach and I stood up and said that we both use numbers out of region. > > What's the big deal? John commented that it wasn't. If that's not > > accurate, I'd be interested in your interpretation. > > Sorry about digging up this old thread... > > The problem (my problem anyway) is that I was just told by ARIN staff (Leslie > Nobile at the event yesterday and confirmed just now via the > helpdesk) that NRPM 4.5 can't be used by an ARIN member to request > resources to be used out of region and, perhaps more troubling, that v4 > space used out of region does not count towards calculating space > utilization when an organization requests additional space from ARIN unless > a less specific route is advertised in-region. > > I wasn't prepared to argue about either of these "policies" yesterday, but > after searching the NRPM, I can't find any basis for either of them. So, I > called the helpdesk to double-check / ask where in the NRPM I could find > these "policies". I was told they're based on ARIN's interpretation of 2.2, > specifically "The primary role of RIRs is to manage and distribute public > Internet address space within their respective regions." Those are some very > specific "policies" derived from a very vague sentence, which I think could > just as reasonably be interpreted as meaning the RIRs exist to serve > organizations headquartered in their respective service regions. > You're a US corporation, ARIN is your RIR. You're a German corporation, > RIPE is your RIR. > > >> "The requirement to have a minimal level of resources deployed in the > >> region (/44 for IPv6, /22 for IPv4, 1 ASN) is an attempt to respond > >> to law enforcement and some community concerns. An absolute > threshold > >> ensures that those applying for ARIN resources are actually operating > >> in the region and not simply a shell company, but it avoids the known > >> pitfalls of trying to use percentages of the organization's overall > >> holdings to do that." > > I think I understand the intent of that requirement, but it's kind of pointless, > especially as currently written: > > ARIN registered resources may be used outside the ARIN service region. > Out of region use of IPv4, IPv6, or ASNs are valid justification for > additional number resources if the applicant is currently using at least > the equivalent of a /22 of IPv4, /44 of IPv6, or 1 ASN within the ARIN > service region, respectively. > > If I were a European org wanting to get space from ARIN instead of RIPE, all I > have to do is buy a VM on some ARIN-region cloud provider, get them to do > BGP with my VM, and I've satisfied the requirement? If you think that's far > fetched, see the recent thread on NANOG about cloud providers willing to > do BGP with VMs. All that does is slightly increase the cost of violating the > intent of the policy. > > I think 2014-1 shouldn't be necessary, but since current ARIN "policy" is > based on an interpretation I disagree with of vague language in section 2, I > suppose I'm all for passage of 2014-1. > > I just hope it doesn't have the sort of unintended consequences I think it > could easily have. Does the helpdesk have many staffers who speak > Romanian? > > ---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > | therefore you are _________ > http://www.lewis.org/~jlewis/pgp for PGP public key_________ From hannigan at gmail.com Wed Feb 25 16:50:51 2015 From: hannigan at gmail.com (Martin Hannigan) Date: Wed, 25 Feb 2015 16:50:51 -0500 Subject: [arin-ppml] 2014-1 Out of Region Use In-Reply-To: References: <91f996151ef44b03b2179e253c0af1db@EX13-MBX-13.ad.syr.edu> <5447331D.9040009@ipinc.net> <4cbf6e7c109641259f86835fc5435cce@EX13-MBX-13.ad.syr.edu> Message-ID: <578DFE36-AC57-4805-88A8-C558B6BBB104@gmail.com> Probably do what the rest of us do? Anchor the allocated prefix in "the region" and call it a day. This seems seriously anti competitive, hence my own desire for a sixth, Depository?, RIR. If we had one or even many this would not be an issue. YMMV. Best, -M< > On Feb 25, 2015, at 16:43, Milton L Mueller wrote: > > Jon > Yes, it's clear that you support the intent of 2014-1, which is to reconcile actual staff practice with an approved policy. But it also sounds like you think our threshold requirement can be gamed? The "speaking Romanian" issue (or more likely, speaking Chinese) has been the subject of fierce debates. Do you have specific suggestions for how we could fix this? > > --MM > >> -----Original Message----- >> From: Jon Lewis [mailto:jlewis at lewis.org] >> Sent: Wednesday, February 25, 2015 1:10 PM >> To: Martin Hannigan >> Cc: Milton L Mueller; arin-ppml at arin.net >> Subject: Re: [arin-ppml] 2014-1 Out of Region Use >> >> On Wed, 22 Oct 2014, Martin Hannigan wrote: >> >>>>> resources stating that this is a no op as well: already using >>>>> numbers in other regions and even ARIN (Curran) chimed in and said >>>>> that it wasn't a problem. >>>> >>>> I think you're interpretation of the situation is WAY out of line >>>> with the reality. Staff wants to STOP out of region use, and is doing >>>> so de facto because of the ambiguities in the policy. Yes, lots of >>>> people are already using numbers in other regions but if you want to >>>> continue to do that with new requests we need to solidify the policy >>>> and make it clear that this is ok. >>> >>> I don't think I took the discussion out of context at all. Both Matt >>> Petach and I stood up and said that we both use numbers out of region. >>> What's the big deal? John commented that it wasn't. If that's not >>> accurate, I'd be interested in your interpretation. >> >> Sorry about digging up this old thread... >> >> The problem (my problem anyway) is that I was just told by ARIN staff (Leslie >> Nobile at the event yesterday and confirmed just now via the >> helpdesk) that NRPM 4.5 can't be used by an ARIN member to request >> resources to be used out of region and, perhaps more troubling, that v4 >> space used out of region does not count towards calculating space >> utilization when an organization requests additional space from ARIN unless >> a less specific route is advertised in-region. >> >> I wasn't prepared to argue about either of these "policies" yesterday, but >> after searching the NRPM, I can't find any basis for either of them. So, I >> called the helpdesk to double-check / ask where in the NRPM I could find >> these "policies". I was told they're based on ARIN's interpretation of 2.2, >> specifically "The primary role of RIRs is to manage and distribute public >> Internet address space within their respective regions." Those are some very >> specific "policies" derived from a very vague sentence, which I think could >> just as reasonably be interpreted as meaning the RIRs exist to serve >> organizations headquartered in their respective service regions. >> You're a US corporation, ARIN is your RIR. You're a German corporation, >> RIPE is your RIR. >> >>>> "The requirement to have a minimal level of resources deployed in the >>>> region (/44 for IPv6, /22 for IPv4, 1 ASN) is an attempt to respond >>>> to law enforcement and some community concerns. An absolute >> threshold >>>> ensures that those applying for ARIN resources are actually operating >>>> in the region and not simply a shell company, but it avoids the known >>>> pitfalls of trying to use percentages of the organization's overall >>>> holdings to do that." >> >> I think I understand the intent of that requirement, but it's kind of pointless, >> especially as currently written: >> >> ARIN registered resources may be used outside the ARIN service region. >> Out of region use of IPv4, IPv6, or ASNs are valid justification for >> additional number resources if the applicant is currently using at least >> the equivalent of a /22 of IPv4, /44 of IPv6, or 1 ASN within the ARIN >> service region, respectively. >> >> If I were a European org wanting to get space from ARIN instead of RIPE, all I >> have to do is buy a VM on some ARIN-region cloud provider, get them to do >> BGP with my VM, and I've satisfied the requirement? If you think that's far >> fetched, see the recent thread on NANOG about cloud providers willing to >> do BGP with VMs. All that does is slightly increase the cost of violating the >> intent of the policy. >> >> I think 2014-1 shouldn't be necessary, but since current ARIN "policy" is >> based on an interpretation I disagree with of vague language in section 2, I >> suppose I'm all for passage of 2014-1. >> >> I just hope it doesn't have the sort of unintended consequences I think it >> could easily have. Does the helpdesk have many staffers who speak >> Romanian? >> >> ---------------------------------------------------------------------- >> Jon Lewis, MCP :) | I route >> | therefore you are _________ >> http://www.lewis.org/~jlewis/pgp for PGP public key_________ From mueller at syr.edu Wed Feb 25 16:53:58 2015 From: mueller at syr.edu (Milton L Mueller) Date: Wed, 25 Feb 2015 21:53:58 +0000 Subject: [arin-ppml] 2014-1 Out of Region Use In-Reply-To: <54EE4079.9060202@sprunk.org> References: <91f996151ef44b03b2179e253c0af1db@EX13-MBX-13.ad.syr.edu> <5447331D.9040009@ipinc.net> <4cbf6e7c109641259f86835fc5435cce@EX13-MBX-13.ad.syr.edu> <54EE4079.9060202@sprunk.org> Message-ID: So, if I'm a German corporation and I don't like RIPE's rules, I simply set up a shell corporation in the US and get my addresses from ARIN, then use them in Germany anyway? That doesn't sound right. MM: There are these things called multinational corporations with global networks. Ever heard of them? Making internet conform to national jurisdictions doesn?t sound right; indeed, it sounds a lot worse than what you call ?registry shopping.? There is strong community support for one-stop shopping for number needs for global networks. Such registry shopping will inevitably result in a "race to the bottom" and defeat the entire rationale for having regional registries. MM: This is a slogan not an argument. Tell me what the incentives of an RIR are to ?race to the bottom? are, please? Most race to the bottom arguments involve benefits or profits that accrue from loosening requirements. Tell me how ARIN or RIPE or APNIC has an incentive to race to the bottom in the distribution of numbers. It seems they almost have the opposite incentive; they want to conserve their local number allocations. IMHO, addresses should come from the registry for the region in which they're used, MM: Numbers are virtual resources that have no intrinsic tie to geography. RIRs were created to make face to face and administrative interactions easier due to variations in language, culture, etc, not to link numbers to territory. Tell me how the internet or the public benefits by requiring transnational networks to get membership in and participate in 5 different organizations for a single network. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Wed Feb 25 17:25:05 2015 From: jcurran at arin.net (John Curran) Date: Wed, 25 Feb 2015 22:25:05 +0000 Subject: [arin-ppml] 2014-1 Out of Region Use In-Reply-To: <578DFE36-AC57-4805-88A8-C558B6BBB104@gmail.com> References: <91f996151ef44b03b2179e253c0af1db@EX13-MBX-13.ad.syr.edu> <5447331D.9040009@ipinc.net> <4cbf6e7c109641259f86835fc5435cce@EX13-MBX-13.ad.syr.edu> <578DFE36-AC57-4805-88A8-C558B6BBB104@gmail.com> Message-ID: <92B4FCA9-154D-437A-9F7D-C102B42AA512@corp.arin.net> On Feb 25, 2015, at 4:50 PM, Martin Hannigan wrote: > Probably do what the rest of us do? Anchor the allocated prefix in "the region" and call it a day. > > This seems seriously anti competitive, hence my own desire for a sixth, Depository?, RIR. > If we had one or even many this would not be an issue. YMMV. Martin - The draft policy in question is regarding criteria for distribution of addresses from the free pool, whereas Depository specifically asserts to be a "post-distribution Registrar" You might need to elaborate on the relationship you see between the two, as your commingling of these is otherwise inexplicable. Thanks! /John John Curran President and CEO ARIN From jlewis at lewis.org Wed Feb 25 17:31:41 2015 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 25 Feb 2015 17:31:41 -0500 (EST) Subject: [arin-ppml] 2014-1 Out of Region Use In-Reply-To: References: <91f996151ef44b03b2179e253c0af1db@EX13-MBX-13.ad.syr.edu> <5447331D.9040009@ipinc.net> <4cbf6e7c109641259f86835fc5435cce@EX13-MBX-13.ad.syr.edu> Message-ID: On Wed, 25 Feb 2015, Milton L Mueller wrote: > Jon > Yes, it's clear that you support the intent of 2014-1, which is to > reconcile actual staff practice with an approved policy. But it also > sounds like you think our threshold requirement can be gamed? The > "speaking Romanian" issue (or more likely, speaking Chinese) has been > the subject of fierce debates. Do you have specific suggestions for how > we could fix this? I haven't thought of anything yet that I don't think would be trivial to game. Operating in region could be accomplished with as little as one cloud VM. "Doing business in" could be done with a Delaware shell company that "exists in region", but only on paper. This may be too arbitrary, but what if to qualify to be permitted to use/request resources from ARIN for out of region use, in addition to what's already in 2014-1, you had to be an ARIN member for some minimum amount of time (i.e. already have resources managed by ARIN)? 1 year? The idea would be to make it harder for a completely "out of region" entity to come to ARIN under this new policy and game the system and use ARIN as an alternative to their "local" RIR. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From alh-ietf at tndh.net Wed Feb 25 18:15:38 2015 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 25 Feb 2015 15:15:38 -0800 Subject: [arin-ppml] 2014-1 Out of Region Use In-Reply-To: References: <91f996151ef44b03b2179e253c0af1db@EX13-MBX-13.ad.syr.edu> <5447331D.9040009@ipinc.net> <4cbf6e7c109641259f86835fc5435cce@EX13-MBX-13.ad.syr.edu> Message-ID: <004801d05150$f7875760$e6960620$@tndh.net> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Jon Lewis > Sent: Wednesday, February 25, 2015 2:32 PM > To: Milton L Mueller > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] 2014-1 Out of Region Use > > On Wed, 25 Feb 2015, Milton L Mueller wrote: > > > Jon > > Yes, it's clear that you support the intent of 2014-1, which is to > > reconcile actual staff practice with an approved policy. But it also > > sounds like you think our threshold requirement can be gamed? The > > "speaking Romanian" issue (or more likely, speaking Chinese) has been > > the subject of fierce debates. Do you have specific suggestions for > > how we could fix this? > > I haven't thought of anything yet that I don't think would be trivial to game. > Operating in region could be accomplished with as little as one cloud VM. > "Doing business in" could be done with a Delaware shell company that "exists > in region", but only on paper. > > This may be too arbitrary, but what if to qualify to be permitted to > use/request resources from ARIN for out of region use, in addition to what's > already in 2014-1, you had to be an ARIN member for some minimum > amount of time (i.e. already have resources managed by ARIN)? 1 year? > The idea would be to make it harder for a completely "out of region" > entity to come to ARIN under this new policy and game the system and use > ARIN as an alternative to their "local" RIR. Back up and figure out what problem is being solved. The primary reason RIR's became possessive about their territory was "absurd protection of their precious IPv4 allocations". Rewind to the pre-RIR timeframe, and allocations were global, and use was global. The RIRs were brought in to simplify the process, not fragment it. 10 years ago I suggested that once the IANA pool was depleted that the RIR holding the largest block take that role, so that the customer interface could remain the same within each region, and the entire pool could burn down smoothly. I was shouted down globally because the greedy wanted to horde whatever they managed to get from IANA. Are we trying to protect the RIR's claimed autonomy over geography, or simplify the process of distribution for a global resource? If it is the latter as it started out to be, the definition of "out of region" is off-planet. If it is the former, why do people continue to fight against NIR's? If you want absolute autonomy, you need somebody capable of protecting your defined geography, and that usually becomes police or military. Make up your collective mind about your stated objective and make policy fit that. As far as I know the stated objective is to facilitate allocations of a global resource, so trying to restrict what the recipient does with it would appear to be out of scope. Tony From jcurran at arin.net Wed Feb 25 20:04:19 2015 From: jcurran at arin.net (John Curran) Date: Thu, 26 Feb 2015 01:04:19 +0000 Subject: [arin-ppml] 2014-1 Out of Region Use In-Reply-To: <004801d05150$f7875760$e6960620$@tndh.net> References: <91f996151ef44b03b2179e253c0af1db@EX13-MBX-13.ad.syr.edu> <5447331D.9040009@ipinc.net> <4cbf6e7c109641259f86835fc5435cce@EX13-MBX-13.ad.syr.edu> <004801d05150$f7875760$e6960620$@tndh.net> Message-ID: <1288BBE4-187C-4530-A77B-59D1F4817537@corp.arin.net> On Feb 25, 2015, at 6:15 PM, Tony Hain wrote: > ... > Back up and figure out what problem is being solved. The primary reason > RIR's became possessive about their territory was "absurd protection of > their precious IPv4 allocations". Rewind to the pre-RIR timeframe, and > allocations were global, and use was global. The RIRs were brought in to > simplify the process, not fragment it. Indeed. Regional Internet Registries provide for support in local languages and with user friendly operating hours. It is also true that RIR's can provide support for regional registry policies that may be better adapted to local conditions. > ... > Are we trying to protect the RIR's claimed autonomy over geography, or > simplify the process of distribution for a global resource? As I understand the origin of draft policy 2014-1, it would be the latter. The original intent was to clarify the circumstances under which ARIN should issue space to service providers who operate principally outside the ARIN region. The first attempts at policy in this area specified that parties had to be operating within the region to receive resources and such resources would be for use in the region, but that did not gain support. As a result, the present draft policy proposes that any party having a minimal legal and operational presence be provided resources, including those needed based on the global need. FYI, /John John Curran President and CEO ARIN From farmer at umn.edu Thu Feb 26 00:30:44 2015 From: farmer at umn.edu (David Farmer) Date: Wed, 25 Feb 2015 23:30:44 -0600 Subject: [arin-ppml] 2014-1 Out of Region Use In-Reply-To: <1288BBE4-187C-4530-A77B-59D1F4817537@corp.arin.net> References: <91f996151ef44b03b2179e253c0af1db@EX13-MBX-13.ad.syr.edu> <5447331D.9040009@ipinc.net> <4cbf6e7c109641259f86835fc5435cce@EX13-MBX-13.ad.syr.edu> <004801d05150$f7875760$e6960620$@tndh.net> <1288BBE4-187C-4530-A77B-59D1F4817537@corp.arin.net> Message-ID: > On Feb 25, 2015, at 19:04, John Curran wrote: > .... > As I understand the origin of draft policy 2014-1, it would be the latter. > The original intent was to clarify the circumstances under which ARIN should > issue space to service providers who operate principally outside the ARIN > region. "Principally outside" might be a bit strong, but clearly "outside" with little or no limits on the quantity of resources used outside the region. > The first attempts at policy in this area specified that parties had > to be operating within the region to receive resources and such resources would > be for use in the region, but that did not gain support. As a result, the > present draft policy proposes that any party having a minimal legal and > operational presence be provided resources, including those needed based > on the global need. I think everyone agrees entities getting resources from ARIN need a nexus with the ARIN region, a legal presence and operations within the region, but it's been difficult to get consensus quantifying how much or how little nexus is necessary, beyond simply having one. Put another way, I don't think anyone thinks entities with no legal presence or operations within the ARIN region should be getting resources from ARIN. But consensus on limits or requirements beyond that has been difficult. > FYI, > /John > > John Curran > President and CEO > ARIN -- =============================================== David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: +1-612-626-0815 Minneapolis, MN 55414-3029 Cell: +1-612-812-9952 =============================================== From jlewis at lewis.org Thu Feb 26 00:37:51 2015 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 26 Feb 2015 00:37:51 -0500 (EST) Subject: [arin-ppml] 2014-1 Out of Region Use In-Reply-To: <54EE4079.9060202@sprunk.org> References: <91f996151ef44b03b2179e253c0af1db@EX13-MBX-13.ad.syr.edu> <5447331D.9040009@ipinc.net> <4cbf6e7c109641259f86835fc5435cce@EX13-MBX-13.ad.syr.edu> <54EE4079.9060202@sprunk.org> Message-ID: On Wed, 25 Feb 2015, Stephen Sprunk wrote: > So, if I'm a German corporation and I don't like RIPE's rules, I simply > set up a shell corporation in the US and get my addresses from ARIN, > then use them in Germany anyway? That doesn't sound right. But the flip side of that is, I'm a US corporation with network assets in the US, Japan, Brazil, Germany, and numerous other countries. Am I supposed to work with ARIN, APNIC, LACNIC, and RIPE to get resources for each country from the local RIR? I'd much rather keep things simpler and deal with one RIR and one RIR's policies. I doubt I'm alone in that sentiment. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From ms258322 at gmail.com Thu Feb 26 02:23:31 2015 From: ms258322 at gmail.com (Mike Smith) Date: Thu, 26 Feb 2015 16:23:31 +0900 Subject: [arin-ppml] incorrect database info cause routing issue In-Reply-To: <65445B8D-65C0-4231-9DE4-2A0A58541BD6@corp.arin.net> References: <78a1fca4754546b795d52a2ba7b75ac9@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> <65445B8D-65C0-4231-9DE4-2A0A58541BD6@corp.arin.net> Message-ID: Hi I have been told by your Hostmaster it has been resolved, however, equiriy to Whois.afrinic.net or Whois.arin.net still shows different results. Example would be 45.208.0.0, anyone can try. On Wednesday, February 25, 2015, John Curran wrote: > Mike - > > Please email hostmaster at arin.net > if you believe > there to be an inconsistency > in the ARIN Whois database. Please be as precise as possible regarding > the > entries that you are concerned about, and we will research and respond > directly. > > Thanks! > /John > > John Curran > President and CEO > ARIN > > On Feb 24, 2015, at 9:55 PM, Mike Smith > wrote: > > > Hi > > I have sent them an email and seems no reply. Can any one from Arin > clarify how to report their DB inconsistency? > > On Wednesday, February 25, 2015, CJ Aronson > wrote: > >> This is a public policy mailing list. If you want to contact ARIN you >> may have better results by using their Contact US info >> >> https://www.arin.net/contact_us.html >> >> Just a thought. >> >> -----Cathy >> >> >> {?,?} >> (( )) >> ? ? >> >> On Tue, Feb 24, 2015 at 7:04 PM, Mike Smith wrote: >> >>> Can anyone from ARIN correct such obvious error. >>> >>> >>> On Wednesday, February 25, 2015, Mike Smith wrote: >>> >>>> Hi >>>> >>>> The second half in ARIN DB shows incorrect detail. >>>> >>>> And ARIN DB claim 45/8 is managed by ARIN. >>>> >>>> On Wednesday, February 25, 2015, Leo Vegoda >>>> wrote: >>>> >>>>> Mike Smith wrote: >>>>> >>>>> [...] >>>>> >>>>> > Following block has been assgined to Afrinic however it still shows >>>>> > ARIN block in the db. >>>>> > >>>>> > 45.160.0.0-45.255.255.255. >>>>> > >>>>> > Please check it and correct it. >>>>> >>>>> 45.160.0.0 - 45.191.255.255 was allocated to LACNIC in May last year >>>>> ( >>>>> https://www.iana.org/assignments/ipv4-recovered-address-space/ipv4-recovered-address-space.xhtml#ipv4-recovered-address-space-2 >>>>> ) >>>>> and ARIN's whois server redirects to LACNIC's when queried for >>>>> addresses in >>>>> that range: >>>>> >>>>> $ whois -h whois.arin.net 45.160.0.0 >>>>> [Querying whois.arin.net] >>>>> [Redirected to whois.lacnic.net] >>>>> [Querying whois.lacnic.net] >>>>> [whois.lacnic.net] >>>>> >>>>> % Joint Whois - whois.lacnic.net >>>>> % This server accepts single ASN, IPv4 or IPv6 queries >>>>> >>>>> It is only the second half of the 45.160.0.0 - 45.255.255.255 that is >>>>> allocated to AFRINIC. >>>>> >>>>> Regards, >>>>> >>>>> Leo Vegoda >>>>> >>>> >>> _______________________________________________ >>> 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 jcurran at arin.net Thu Feb 26 06:47:31 2015 From: jcurran at arin.net (John Curran) Date: Thu, 26 Feb 2015 11:47:31 +0000 Subject: [arin-ppml] incorrect database info cause routing issue In-Reply-To: References: <78a1fca4754546b795d52a2ba7b75ac9@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> <65445B8D-65C0-4231-9DE4-2A0A58541BD6@corp.arin.net> Message-ID: <6F40F85C-F098-4C95-9DA0-E0190AD97D2B@arin.net> On Feb 26, 2015, at 2:23 AM, Mike Smith > wrote: Hi I have been told by your Hostmaster it has been resolved, however, equiriy to Whois.afrinic.net or Whois.arin.net still shows different results. Example would be 45.208.0.0, anyone can try. Mike - ARIN administers the 45/8 address block; there are specific subranges that are allocated to various RIRs, e.g. 45.192.0.0 - 45.222.255.255 to AFRINIC. You will this reflected in your Whois query results. Thanks, /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From ms258322 at gmail.com Thu Feb 26 07:01:38 2015 From: ms258322 at gmail.com (Mike Smith) Date: Thu, 26 Feb 2015 21:01:38 +0900 Subject: [arin-ppml] incorrect database info cause routing issue In-Reply-To: <6F40F85C-F098-4C95-9DA0-E0190AD97D2B@arin.net> References: <78a1fca4754546b795d52a2ba7b75ac9@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> <65445B8D-65C0-4231-9DE4-2A0A58541BD6@corp.arin.net> <6F40F85C-F098-4C95-9DA0-E0190AD97D2B@arin.net> Message-ID: Hi Please see below, anyone else can help test both DB and see the inconsistency? Carels-Air:~ carel$ whois 45.195.0.0 # # ARIN WHOIS data and services are subject to the Terms of Use # available at: https://www.arin.net/whois_tou.html # # If you see inaccuracies in the results, please report at # http://www.arin.net/public/whoisinaccuracy/index.xhtml # # # Query terms are ambiguous. The query is assumed to be: # "n 45.195.0.0" # # Use "?" to get help. # No match found for 45.195.0.0. # # ARIN WHOIS data and services are subject to the Terms of Use # available at: https://www.arin.net/whois_tou.html # # If you see inaccuracies in the results, please report at # http://www.arin.net/public/whoisinaccuracy/index.xhtml # Carels-Air:~ carel$ whois -h whois.afrinic.net45.1950.0 % This is the AfriNIC Whois server. % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '45.192.0.0 - 45.199.255.255' % No abuse contact registered for 45.192.0.0 - 45.199255.255 inetnum: 45.192.0.0 - 45.199.255.255 netname: CloudInnovation descr: CloudInnovation infrastructure country: ZA admin-c: OS9-AFRINIC tech-c: OS9-AFRINIC status: ASSIGNED PA mnt-by: CIL1-MNT mnt-routes: CIL1-MNT source: AFRINIC # Filtered parent: 45.192.0.0 - 45.207.255.255 person: OutsideHeaven Support nic-hdl: OS9-AFRINIC address: Ebene address: MU address: Mahe address: Seychelles phone: +248 4 610 795 <+248%204%20610%20795> source: AFRINIC # Filtered On Thursday, February 26, 2015, John Curran wrote: > On Feb 26, 2015, at 2:23 AM, Mike Smith > wrote: > > > Hi > > I have been told by your Hostmaster it has been resolved, however, > equiriy to Whois.afrinic.net or Whois.arin.net > still shows different results. > > Example would be 45.208.0.0, anyone can try. > > > Mike - > > ARIN administers the 45/8 address block; there are specific subranges > that are > allocated to various RIRs, e.g. 45.192.0.0 - 45.222.255.255 to AFRINIC. > You > will this reflected in your Whois query results. > > Thanks, > /John > > John Curran > President and CEO > ARIN > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mueller at syr.edu Thu Feb 26 09:29:21 2015 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 26 Feb 2015 14:29:21 +0000 Subject: [arin-ppml] 2014-1 Out of Region Use In-Reply-To: <004801d05150$f7875760$e6960620$@tndh.net> References: <91f996151ef44b03b2179e253c0af1db@EX13-MBX-13.ad.syr.edu> <5447331D.9040009@ipinc.net> <4cbf6e7c109641259f86835fc5435cce@EX13-MBX-13.ad.syr.edu> <004801d05150$f7875760$e6960620$@tndh.net> Message-ID: <6b54c2df21394ae086fb594a43607a83@EX13-MBX-13.ad.syr.edu> What he (Tony Hain) said! Anyway, by the time 2014-1 gets implemented, the ARIN IPv4 free pool would be depleted, and since most of the potential abuses of or questionable demand for out of region use are motivated by ARIN's having the last free pool, I believe the gaming argument is moot in a few months. > -----Original Message----- > From: Tony Hain [mailto:alh-ietf at tndh.net] > Back up and figure out what problem is being solved. The primary reason > RIR's became possessive about their territory was "absurd protection of their > precious IPv4 allocations". Rewind to the pre-RIR timeframe, and allocations > were global, and use was global. The RIRs were brought in to simplify the > process, not fragment it. 10 years ago I suggested that once the IANA pool > was depleted that the RIR holding the largest block take that role, so that > the customer interface could remain the same within each region, and the > entire pool could burn down smoothly. I was shouted down globally because > the greedy wanted to horde whatever they managed to get from IANA. > > Are we trying to protect the RIR's claimed autonomy over geography, or > simplify the process of distribution for a global resource? If it is the latter as > it started out to be, the definition of "out of region" is off-planet. If it is the > former, why do people continue to fight against NIR's? If you want absolute > autonomy, you need somebody capable of protecting your defined > geography, and that usually becomes police or military. Make up your > collective mind about your stated objective and make policy fit that. As far > as I know the stated objective is to facilitate allocations of a global resource, > so trying to restrict what the recipient does with it would appear to be out > of scope. > > Tony > > From sethm at rollernet.us Thu Feb 26 13:20:35 2015 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 26 Feb 2015 10:20:35 -0800 Subject: [arin-ppml] incorrect database info cause routing issue In-Reply-To: References: <78a1fca4754546b795d52a2ba7b75ac9@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> <65445B8D-65C0-4231-9DE4-2A0A58541BD6@corp.arin.net> <6F40F85C-F098-4C95-9DA0-E0190AD97D2B@arin.net> Message-ID: <54EF63F3.8090806@rollernet.us> On 2/26/15 4:01, Mike Smith wrote: > Hi > > Please see below, anyone else can help test both DB and see the > inconsistency? > Do you think they're supposed to sync or something? ~Seth From ms258322 at gmail.com Thu Feb 26 15:33:15 2015 From: ms258322 at gmail.com (Mike Smith) Date: Fri, 27 Feb 2015 05:33:15 +0900 Subject: [arin-ppml] incorrect database info cause routing issue In-Reply-To: <54EF63F3.8090806@rollernet.us> References: <78a1fca4754546b795d52a2ba7b75ac9@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> <65445B8D-65C0-4231-9DE4-2A0A58541BD6@corp.arin.net> <6F40F85C-F098-4C95-9DA0-E0190AD97D2B@arin.net> <54EF63F3.8090806@rollernet.us> Message-ID: I don't think they support to sync, but where you ask an Afrinic ip in Arin DB, Arin DB should tell it, but not claim it is one of its own. Try ask 45.195.0.0(an Afrinic ip) in Arin DB. On Friday, February 27, 2015, Seth Mattinen wrote: > On 2/26/15 4:01, Mike Smith wrote: > >> Hi >> >> Please see below, anyone else can help test both DB and see the >> inconsistency? >> >> > > Do you think they're supposed to sync or something? > > ~Seth > _______________________________________________ > 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 sethm at rollernet.us Thu Feb 26 15:40:12 2015 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 26 Feb 2015 12:40:12 -0800 Subject: [arin-ppml] incorrect database info cause routing issue In-Reply-To: References: <78a1fca4754546b795d52a2ba7b75ac9@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> <65445B8D-65C0-4231-9DE4-2A0A58541BD6@corp.arin.net> <6F40F85C-F098-4C95-9DA0-E0190AD97D2B@arin.net> <54EF63F3.8090806@rollernet.us> Message-ID: <54EF84AC.2040506@rollernet.us> On 2/26/15 12:33, Mike Smith wrote: > I don't think they support to sync, but where you ask an Afrinic ip in > Arin DB, Arin DB should tell it, but not claim it is one of its own. Try > ask 45.195.0.0(an Afrinic ip) in Arin DB. > Works fine for me. $ whois 45.195.0.0 -h whois.arin.net # # ARIN WHOIS data and services are subject to the Terms of Use # available at: https://www.arin.net/whois_tou.html # # If you see inaccuracies in the results, please report at # http://www.arin.net/public/whoisinaccuracy/index.xhtml # # # The following results may also be obtained via: # http://whois.arin.net/rest/nets;q=45.195.0.0?showDetails=true&showARIN=false&ext=netref2 # NetRange: 45.192.0.0 - 45.222.255.255 CIDR: 45.192.0.0/12, 45.220.0.0/15, 45.208.0.0/13, 45.222.0.0/16, 45.216.0.0/14 NetName: AFRINIC NetHandle: NET-45-192-0-0-1 Parent: NET45 (NET-45-0-0-0-0) NetType: Transferred to AfriNIC OriginAS: Organization: African Network Information Center (AFRINIC) RegDate: 2014-05-22 Updated: 2015-02-26 Ref: http://whois.arin.net/rest/net/NET-45-192-0-0-1 OrgName: African Network Information Center OrgId: AFRINIC Address: Level 11ABC Address: Raffles Tower Address: Lot 19, Cybercity City: Ebene StateProv: PostalCode: Country: MU RegDate: 2004-05-17 Updated: 2010-06-28 Comment: AfriNIC - http://www.afrinic.net Comment: The African & Indian Ocean Internet Registry Ref: http://whois.arin.net/rest/org/AFRINIC ReferralServer: whois://whois.afrinic.net:43 OrgTechHandle: GENER11-ARIN OrgTechName: Generic POC OrgTechPhone: +230 4666616 OrgTechEmail: abusepoc at afrinic.net OrgTechRef: http://whois.arin.net/rest/poc/GENER11-ARIN OrgAbuseHandle: GENER11-ARIN OrgAbuseName: Generic POC OrgAbusePhone: +230 4666616 OrgAbuseEmail: abusepoc at afrinic.net OrgAbuseRef: http://whois.arin.net/rest/poc/GENER11-ARIN # # ARIN WHOIS data and services are subject to the Terms of Use # available at: https://www.arin.net/whois_tou.html # # If you see inaccuracies in the results, please report at # http://www.arin.net/public/whoisinaccuracy/index.xhtml # Found a referral to whois.afrinic.net:43. % This is the AfriNIC Whois server. % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '45.192.0.0 - 45.199.255.255' % No abuse contact registered for 45.192.0.0 - 45.199.255.255 inetnum: 45.192.0.0 - 45.199.255.255 netname: CloudInnovation descr: CloudInnovation infrastructure country: ZA admin-c: OS9-AFRINIC tech-c: OS9-AFRINIC status: ASSIGNED PA mnt-by: CIL1-MNT mnt-routes: CIL1-MNT source: AFRINIC # Filtered parent: 45.192.0.0 - 45.207.255.255 person: OutsideHeaven Support nic-hdl: OS9-AFRINIC address: Ebene address: MU address: Mahe address: Seychelles phone: +248 4 610 795 source: AFRINIC # Filtered From ms258322 at gmail.com Thu Feb 26 15:40:54 2015 From: ms258322 at gmail.com (Mike Smith) Date: Fri, 27 Feb 2015 05:40:54 +0900 Subject: [arin-ppml] incorrect database info cause routing issue In-Reply-To: <54EF84AC.2040506@rollernet.us> References: <78a1fca4754546b795d52a2ba7b75ac9@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> <65445B8D-65C0-4231-9DE4-2A0A58541BD6@corp.arin.net> <6F40F85C-F098-4C95-9DA0-E0190AD97D2B@arin.net> <54EF63F3.8090806@rollernet.us> <54EF84AC.2040506@rollernet.us> Message-ID: Yes, it was just fixed. On Friday, February 27, 2015, Seth Mattinen wrote: > On 2/26/15 12:33, Mike Smith wrote: > >> I don't think they support to sync, but where you ask an Afrinic ip in >> Arin DB, Arin DB should tell it, but not claim it is one of its own. Try >> ask 45.195.0.0(an Afrinic ip) in Arin DB. >> >> > > Works fine for me. > > > $ whois 45.195.0.0 -h whois.arin.net > > # > # ARIN WHOIS data and services are subject to the Terms of Use > # available at: https://www.arin.net/whois_tou.html > # > # If you see inaccuracies in the results, please report at > # http://www.arin.net/public/whoisinaccuracy/index.xhtml > # > > > # > # The following results may also be obtained via: > # http://whois.arin.net/rest/nets;q=45.195.0.0?showDetails= > true&showARIN=false&ext=netref2 > # > > NetRange: 45.192.0.0 - 45.222.255.255 > CIDR: 45.192.0.0/12, 45.220.0.0/15, 45.208.0.0/13, 45.222.0.0/16, > 45.216.0.0/14 > NetName: AFRINIC > NetHandle: NET-45-192-0-0-1 > Parent: NET45 (NET-45-0-0-0-0) > NetType: Transferred to AfriNIC > OriginAS: > Organization: African Network Information Center (AFRINIC) > RegDate: 2014-05-22 > Updated: 2015-02-26 > Ref: http://whois.arin.net/rest/net/NET-45-192-0-0-1 > > OrgName: African Network Information Center > OrgId: AFRINIC > Address: Level 11ABC > Address: Raffles Tower > Address: Lot 19, Cybercity > City: Ebene > StateProv: > PostalCode: > Country: MU > RegDate: 2004-05-17 > Updated: 2010-06-28 > Comment: AfriNIC - http://www.afrinic.net > Comment: The African & Indian Ocean Internet Registry > Ref: http://whois.arin.net/rest/org/AFRINIC > > ReferralServer: whois://whois.afrinic.net:43 > > OrgTechHandle: GENER11-ARIN > OrgTechName: Generic POC > OrgTechPhone: +230 4666616 > OrgTechEmail: abusepoc at afrinic.net > OrgTechRef: http://whois.arin.net/rest/poc/GENER11-ARIN > > OrgAbuseHandle: GENER11-ARIN > OrgAbuseName: Generic POC > OrgAbusePhone: +230 4666616 > OrgAbuseEmail: abusepoc at afrinic.net > OrgAbuseRef: http://whois.arin.net/rest/poc/GENER11-ARIN > > > # > # ARIN WHOIS data and services are subject to the Terms of Use > # available at: https://www.arin.net/whois_tou.html > # > # If you see inaccuracies in the results, please report at > # http://www.arin.net/public/whoisinaccuracy/index.xhtml > # > > > > Found a referral to whois.afrinic.net:43. > > % This is the AfriNIC Whois server. > > % Note: this output has been filtered. > % To receive output for a database update, use the "-B" flag. > > % Information related to '45.192.0.0 - 45.199.255.255' > > % No abuse contact registered for 45.192.0.0 - 45.199.255.255 > > inetnum: 45.192.0.0 - 45.199.255.255 > netname: CloudInnovation > descr: CloudInnovation infrastructure > country: ZA > admin-c: OS9-AFRINIC > tech-c: OS9-AFRINIC > status: ASSIGNED PA > mnt-by: CIL1-MNT > mnt-routes: CIL1-MNT > source: AFRINIC # Filtered > parent: 45.192.0.0 - 45.207.255.255 > > person: OutsideHeaven Support > nic-hdl: OS9-AFRINIC > address: Ebene > address: MU > address: Mahe > address: Seychelles > phone: +248 4 610 795 > source: AFRINIC # Filtered > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Thu Feb 26 15:46:02 2015 From: jcurran at arin.net (John Curran) Date: Thu, 26 Feb 2015 20:46:02 +0000 Subject: [arin-ppml] incorrect database info cause routing issue In-Reply-To: References: <78a1fca4754546b795d52a2ba7b75ac9@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> <65445B8D-65C0-4231-9DE4-2A0A58541BD6@corp.arin.net> <6F40F85C-F098-4C95-9DA0-E0190AD97D2B@arin.net> <54EF63F3.8090806@rollernet.us> Message-ID: <9D850759-79D8-4D64-8F63-7ADE91E04628@corp.arin.net> On Feb 26, 2015, at 3:33 PM, Mike Smith > wrote: I don't think they support to sync, but where you ask an Afrinic ip in Arin DB, Arin DB should tell it, but not claim it is one of its own. Try ask 45.195.0.0(an Afrinic ip) in Arin DB. Attached for 45.195.0.0 If you see inaccuracies in the results, please report at hostmaster at arin.net or http://www.arin.net/public/whoisinaccuracy/index.xhtml Thanks! /John John Curran President and CEO ARIN === j% whois 45.195.0.0 ... NetRange: 45.192.0.0 - 45.222.255.255 CIDR: 45.192.0.0/12, 45.220.0.0/15, 45.208.0.0/13, 45.216.0.0/14, 45.222.0.0/16 NetName: AFRINIC NetHandle: NET-45-192-0-0-1 Parent: NET45 (NET-45-0-0-0-0) NetType: Transferred to AfriNIC OriginAS: Organization: African Network Information Center (AFRINIC) RegDate: 2014-05-22 Updated: 2015-02-26 Ref: http://whois.arin.net/rest/net/NET-45-192-0-0-1 OrgName: African Network Information Center OrgId: AFRINIC Address: Level 11ABC Address: Raffles Tower Address: Lot 19, Cybercity City: Ebene StateProv: PostalCode: Country: MU RegDate: 2004-05-17 Updated: 2010-06-28 Comment: AfriNIC - http://www.afrinic.net Comment: The African & Indian Ocean Internet Registry Ref: http://whois.arin.net/rest/org/AFRINIC ReferralServer: whois://whois.afrinic.net:43 OrgTechHandle: GENER11-ARIN OrgTechName: Generic POC OrgTechPhone: +230 4666616 OrgTechEmail: abusepoc at afrinic.net OrgTechRef: http://whois.arin.net/rest/poc/GENER11-ARIN OrgAbuseHandle: GENER11-ARIN OrgAbuseName: Generic POC OrgAbusePhone: +230 4666616 OrgAbuseEmail: abusepoc at afrinic.net OrgAbuseRef: http://whois.arin.net/rest/poc/GENER11-ARIN # # ARIN WHOIS data and services are subject to the Terms of Use # available at: https://www.arin.net/whois_tou.html # # If you see inaccuracies in the results, please report at # http://www.arin.net/public/whoisinaccuracy/index.xhtml -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu Feb 26 16:07:38 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 26 Feb 2015 13:07:38 -0800 Subject: [arin-ppml] incorrect database info cause routing issue In-Reply-To: References: <78a1fca4754546b795d52a2ba7b75ac9@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> <65445B8D-65C0-4231-9DE4-2A0A58541BD6@corp.arin.net> <6F40F85C-F098-4C95-9DA0-E0190AD97D2B@arin.net> Message-ID: <07EC4777-2355-4537-9C1A-DBE36FAB5C22@delong.com> Most likely this is more a case of ARIN refusing to maintain a decent UI on command-line whois and focusing all their efforts on the RESTful interface on the web server? Here?s what I get from that: Net Range 45.192.0.0 - 45.222.255.255 CIDR 45.192.0.0/12 45.208.0.0/13 45.216.0.0/14 45.220.0.0/15 45.222.0.0/16 Name AFRINIC Handle NET-45-192-0-0-1 Parent NET45 (NET-45-0-0-0-0 ) Net Type Transferred to AfriNIC Origin AS Organization African Network Information Center (AFRINIC ) Registration Date 2014-05-22 Last Updated 2015-02-26 Comments RESTful Link http://whois.arin.net/rest/net/NET-45-192-0-0-1 See Also Related organization's POC records. See Also Related delegations. Organization Name African Network Information Center Handle AFRINIC Street Level 11ABC Raffles Tower Lot 19, Cybercity City Ebene State/Province Postal Code Country MU Registration Date 2004-05-17 Last Updated 2010-06-28 Comments AfriNIC - http://www.afrinic.net The African & Indian Ocean Internet Registry RESTful Link http://whois.arin.net/rest/org/AFRINIC Referral Server whois://whois.afrinic.net:43 Function Point of Contact Tech GENER11-ARIN (GENER11-ARIN ) Admin GENER11-ARIN (GENER11-ARIN ) Abuse GENER11-ARIN (GENER11-ARIN ) It would be nice if ARIN would fix the command line whois server, but so far, my efforts to get them to do so have been fruitless. Owen > On Feb 26, 2015, at 4:01 AM, Mike Smith wrote: > > Hi > > Please see below, anyone else can help test both DB and see the inconsistency? > > > Carels-Air:~ carel$ whois 45.195.0.0 > > # > # ARIN WHOIS data and services are subject to the Terms of Use > # available at: https://www.arin.net/whois_tou.html > # > # If you see inaccuracies in the results, please report at > # http://www.arin.net/public/whoisinaccuracy/index.xhtml > # > > > # > # Query terms are ambiguous. The query is assumed to be: > # "n 45.195.0.0" > # > # Use "?" to get help. > # > > No match found for 45.195.0.0. > > > > > # > # ARIN WHOIS data and services are subject to the Terms of Use > # available at: https://www.arin.net/whois_tou.html > # > # If you see inaccuracies in the results, please report at > # http://www.arin.net/public/whoisinaccuracy/index.xhtml > # > > Carels-Air:~ carel$ whois -h whois.afrinic.net 45.1950.0 > % This is the AfriNIC Whois server. > > % Note: this output has been filtered. > % To receive output for a database update, use the "-B" flag. > > % Information related to '45.192.0.0 - 45.199.255.255' > > % No abuse contact registered for 45.192.0.0 - 45.199255.255 > > inetnum: 45.192.0.0 - 45.199.255.255 > netname: CloudInnovation > descr: CloudInnovation infrastructure > country: ZA > admin-c: OS9-AFRINIC > tech-c: OS9-AFRINIC > status: ASSIGNED PA > mnt-by: CIL1-MNT > mnt-routes: CIL1-MNT > source: AFRINIC # Filtered > parent: 45.192.0.0 - 45.207.255.255 > > person: OutsideHeaven Support > nic-hdl: OS9-AFRINIC > address: Ebene > address: MU > address: Mahe > address: Seychelles > phone: +248 4 610 795 > source: AFRINIC # Filtered > > > On Thursday, February 26, 2015, John Curran > wrote: > On Feb 26, 2015, at 2:23 AM, Mike Smith > wrote: >> >> Hi >> >> I have been told by your Hostmaster it has been resolved, however, equiriy to Whois.afrinic.net or Whois.arin.net still shows different results. >> >> Example would be 45.208.0.0, anyone can try. > > Mike - > > ARIN administers the 45/8 address block; there are specific subranges that are > allocated to various RIRs, e.g. 45.192.0.0 - 45.222.255.255 to AFRINIC. You > will this reflected in your Whois query results. > > Thanks, > /John > > John Curran > President and CEO > ARIN > > > > _______________________________________________ > 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 adudek16 at gmail.com Thu Feb 26 16:33:07 2015 From: adudek16 at gmail.com (Aaron Dudek) Date: Thu, 26 Feb 2015 16:33:07 -0500 Subject: [arin-ppml] incorrect database info cause routing issue In-Reply-To: <07EC4777-2355-4537-9C1A-DBE36FAB5C22@delong.com> References: <78a1fca4754546b795d52a2ba7b75ac9@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> <65445B8D-65C0-4231-9DE4-2A0A58541BD6@corp.arin.net> <6F40F85C-F098-4C95-9DA0-E0190AD97D2B@arin.net> <07EC4777-2355-4537-9C1A-DBE36FAB5C22@delong.com> Message-ID: it's a cli. what kind of ui are you looking for? On Thursday, February 26, 2015, Owen DeLong wrote: > Most likely this is more a case of ARIN refusing to maintain a decent UI > on command-line whois and focusing all their efforts on the RESTful > interface on the web server? > > Here?s what I get from that: > > Net Range45.192.0.0 - 45.222.255.255CIDR45.192.0.0/12 > 45.208.0.0/13 > 45.216.0.0/14 > 45.220.0.0/15 > 45.222.0.0/16 > NameAFRINICHandleNET-45-192-0-0-1ParentNET45 (NET-45-0-0-0-0 > )Net TypeTransferred > to AfriNICOrigin ASOrganizationAfrican Network Information Center (AFRINIC > )Registration Date2014-05-22Last > Updated2015-02-26CommentsRESTful Link > http://whois.arin.net/rest/net/NET-45-192-0-0-1See AlsoRelated > organization's POC records. See > AlsoRelated delegations. > > > OrganizationNameAfrican Network Information CenterHandleAFRINICStreetLevel > 11ABC > Raffles Tower > Lot 19, Cybercity > CityEbeneState/ProvincePostal CodeCountryMURegistration Date2004-05-17Last > Updated2010-06-28CommentsAfriNIC - http://www.afrinic.net > The African & Indian Ocean Internet Registry > RESTful Linkhttp://whois.arin.net/rest/org/AFRINICReferral Server > whois://whois.afrinic.net:43FunctionPoint of ContactTechGENER11-ARIN ( > GENER11-ARIN )AdminGENER11-ARIN > (GENER11-ARIN )AbuseGENER11-ARIN > (GENER11-ARIN ) > > > It would be nice if ARIN would fix the command line whois server, but so > far, my efforts to get them to do so have been fruitless. > > Owen > > On Feb 26, 2015, at 4:01 AM, Mike Smith > wrote: > > Hi > > Please see below, anyone else can help test both DB and see the > inconsistency? > > > Carels-Air:~ carel$ whois 45.195.0.0 > > # > # ARIN WHOIS data and services are subject to the Terms of Use > # available at: https://www.arin.net/whois_tou.html > # > # If you see inaccuracies in the results, please report at > # http://www.arin.net/public/whoisinaccuracy/index.xhtml > # > > > # > # Query terms are ambiguous. The query is assumed to be: > # "n 45.195.0.0" > # > # Use "?" to get help. > # > > No match found for 45.195.0.0. > > > > > # > # ARIN WHOIS data and services are subject to the Terms of Use > # available at: https://www.arin.net/whois_tou.html > # > # If you see inaccuracies in the results, please report at > # http://www.arin.net/public/whoisinaccuracy/index.xhtml > # > > Carels-Air:~ carel$ whois -h whois.afrinic.net45.1950.0 > % This is the AfriNIC Whois server. > > % Note: this output has been filtered. > % To receive output for a database update, use the "-B" flag. > > % Information related to '45.192.0.0 - 45.199.255.255' > > % No abuse contact registered for 45.192.0.0 - 45.199255.255 > > inetnum: 45.192.0.0 - 45.199.255.255 > netname: CloudInnovation > descr: CloudInnovation infrastructure > country: ZA > admin-c: OS9-AFRINIC > tech-c: OS9-AFRINIC > status: ASSIGNED PA > mnt-by: CIL1-MNT > mnt-routes: CIL1-MNT > source: AFRINIC # Filtered > parent: 45.192.0.0 - 45.207.255.255 > > person: OutsideHeaven Support > nic-hdl: OS9-AFRINIC > address: Ebene > address: MU > address: Mahe > address: Seychelles > phone: +248 4 610 795 <+248%204%20610%20795> > source: AFRINIC # Filtered > > > On Thursday, February 26, 2015, John Curran > wrote: > >> On Feb 26, 2015, at 2:23 AM, Mike Smith wrote: >> >> >> Hi >> >> I have been told by your Hostmaster it has been resolved, however, >> equiriy to Whois.afrinic.net or >> Whois.arin.net still shows different results. >> >> Example would be 45.208.0.0, anyone can try. >> >> >> Mike - >> >> ARIN administers the 45/8 address block; there are specific >> subranges that are >> allocated to various RIRs, e.g. 45.192.0.0 - 45.222.255.255 to >> AFRINIC. You >> will this reflected in your Whois query results. >> >> Thanks, >> /John >> >> John Curran >> President and CEO >> ARIN >> >> >> >> > _______________________________________________ > 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 adudek16 at gmail.com Thu Feb 26 16:36:01 2015 From: adudek16 at gmail.com (Aaron Dudek) Date: Thu, 26 Feb 2015 16:36:01 -0500 Subject: [arin-ppml] incorrect database info cause routing issue In-Reply-To: References: <78a1fca4754546b795d52a2ba7b75ac9@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> <65445B8D-65C0-4231-9DE4-2A0A58541BD6@corp.arin.net> <6F40F85C-F098-4C95-9DA0-E0190AD97D2B@arin.net> <07EC4777-2355-4537-9C1A-DBE36FAB5C22@delong.com> Message-ID: besides that it's his application not Arin's, unless I read the output incorrectly On Thursday, February 26, 2015, Aaron Dudek wrote: > it's a cli. what kind of ui are you looking for? > > On Thursday, February 26, 2015, Owen DeLong > wrote: > >> Most likely this is more a case of ARIN refusing to maintain a decent UI >> on command-line whois and focusing all their efforts on the RESTful >> interface on the web server? >> >> Here?s what I get from that: >> >> Net Range45.192.0.0 - 45.222.255.255CIDR45.192.0.0/12 >> 45.208.0.0/13 >> 45.216.0.0/14 >> 45.220.0.0/15 >> 45.222.0.0/16 >> NameAFRINICHandleNET-45-192-0-0-1ParentNET45 (NET-45-0-0-0-0 >> )Net TypeTransferred >> to AfriNICOrigin ASOrganizationAfrican Network Information Center ( >> AFRINIC )Registration Date >> 2014-05-22Last Updated2015-02-26CommentsRESTful Link >> http://whois.arin.net/rest/net/NET-45-192-0-0-1See AlsoRelated >> organization's POC records. See >> AlsoRelated delegations. >> >> >> OrganizationNameAfrican Network Information CenterHandleAFRINICStreetLevel >> 11ABC >> Raffles Tower >> Lot 19, Cybercity >> CityEbeneState/ProvincePostal CodeCountryMURegistration Date2004-05-17Last >> Updated2010-06-28CommentsAfriNIC - http://www.afrinic.net >> The African & Indian Ocean Internet Registry >> RESTful Linkhttp://whois.arin.net/rest/org/AFRINICReferral Server >> whois://whois.afrinic.net:43FunctionPoint of ContactTechGENER11-ARIN ( >> GENER11-ARIN )AdminGENER11-ARIN >> (GENER11-ARIN )AbuseGENER11-ARIN >> (GENER11-ARIN ) >> >> >> It would be nice if ARIN would fix the command line whois server, but so >> far, my efforts to get them to do so have been fruitless. >> >> Owen >> >> On Feb 26, 2015, at 4:01 AM, Mike Smith wrote: >> >> Hi >> >> Please see below, anyone else can help test both DB and see the >> inconsistency? >> >> >> Carels-Air:~ carel$ whois 45.195.0.0 >> >> # >> # ARIN WHOIS data and services are subject to the Terms of Use >> # available at: https://www.arin.net/whois_tou.html >> # >> # If you see inaccuracies in the results, please report at >> # http://www.arin.net/public/whoisinaccuracy/index.xhtml >> # >> >> >> # >> # Query terms are ambiguous. The query is assumed to be: >> # "n 45.195.0.0" >> # >> # Use "?" to get help. >> # >> >> No match found for 45.195.0.0. >> >> >> >> >> # >> # ARIN WHOIS data and services are subject to the Terms of Use >> # available at: https://www.arin.net/whois_tou.html >> # >> # If you see inaccuracies in the results, please report at >> # http://www.arin.net/public/whoisinaccuracy/index.xhtml >> # >> >> Carels-Air:~ carel$ whois -h whois.afrinic.net45.1950.0 >> % This is the AfriNIC Whois server. >> >> % Note: this output has been filtered. >> % To receive output for a database update, use the "-B" flag. >> >> % Information related to '45.192.0.0 - 45.199.255.255' >> >> % No abuse contact registered for 45.192.0.0 - 45.199255.255 >> >> inetnum: 45.192.0.0 - 45.199.255.255 >> netname: CloudInnovation >> descr: CloudInnovation infrastructure >> country: ZA >> admin-c: OS9-AFRINIC >> tech-c: OS9-AFRINIC >> status: ASSIGNED PA >> mnt-by: CIL1-MNT >> mnt-routes: CIL1-MNT >> source: AFRINIC # Filtered >> parent: 45.192.0.0 - 45.207.255.255 >> >> person: OutsideHeaven Support >> nic-hdl: OS9-AFRINIC >> address: Ebene >> address: MU >> address: Mahe >> address: Seychelles >> phone: +248 4 610 795 <+248%204%20610%20795> >> source: AFRINIC # Filtered >> >> >> On Thursday, February 26, 2015, John Curran wrote: >> >>> On Feb 26, 2015, at 2:23 AM, Mike Smith wrote: >>> >>> >>> Hi >>> >>> I have been told by your Hostmaster it has been resolved, however, >>> equiriy to Whois.afrinic.net or >>> Whois.arin.net still shows different results. >>> >>> Example would be 45.208.0.0, anyone can try. >>> >>> >>> Mike - >>> >>> ARIN administers the 45/8 address block; there are specific >>> subranges that are >>> allocated to various RIRs, e.g. 45.192.0.0 - 45.222.255.255 to >>> AFRINIC. You >>> will this reflected in your Whois query results. >>> >>> Thanks, >>> /John >>> >>> John Curran >>> President and CEO >>> ARIN >>> >>> >>> >>> >> _______________________________________________ >> 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 Thu Feb 26 19:17:01 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 26 Feb 2015 16:17:01 -0800 Subject: [arin-ppml] incorrect database info cause routing issue In-Reply-To: References: <78a1fca4754546b795d52a2ba7b75ac9@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> <65445B8D-65C0-4231-9DE4-2A0A58541BD6@corp.arin.net> <6F40F85C-F098-4C95-9DA0-E0190AD97D2B@arin.net> <07EC4777-2355-4537-9C1A-DBE36FAB5C22@delong.com> Message-ID: NO? What I am saying is that the TCP-based whois server at ARIN does not always work as expected. Their focus has been on improving the RESTful server and they have largely ignored the TCP-based server. Owen > On Feb 26, 2015, at 13:36 , Aaron Dudek wrote: > > besides that it's his application not Arin's, unless I read the output incorrectly > > On Thursday, February 26, 2015, Aaron Dudek > wrote: > it's a cli. what kind of ui are you looking for? > > On Thursday, February 26, 2015, Owen DeLong > wrote: > Most likely this is more a case of ARIN refusing to maintain a decent UI on command-line whois and focusing all their efforts on the RESTful interface on the web server? > > Here?s what I get from that: > > Net Range 45.192.0.0 - 45.222.255.255 > CIDR 45.192.0.0/12 > 45.208.0.0/13 > 45.216.0.0/14 > 45.220.0.0/15 > 45.222.0.0/16 > Name AFRINIC > Handle NET-45-192-0-0-1 > Parent NET45 (NET-45-0-0-0-0 ) > Net Type Transferred to AfriNIC > Origin AS > Organization African Network Information Center (AFRINIC ) > Registration Date 2014-05-22 > Last Updated 2015-02-26 > Comments > RESTful Link http://whois.arin.net/rest/net/NET-45-192-0-0-1 > See Also Related organization's POC records. > See Also Related delegations. > > Organization > Name African Network Information Center > Handle AFRINIC > Street Level 11ABC > Raffles Tower > Lot 19, Cybercity > City Ebene > State/Province > Postal Code > Country MU > Registration Date 2004-05-17 > Last Updated 2010-06-28 > Comments AfriNIC - http://www.afrinic.net > The African & Indian Ocean Internet Registry > RESTful Link http://whois.arin.net/rest/org/AFRINIC > Referral Server whois://whois.afrinic.net:43 <> > Function Point of Contact > Tech GENER11-ARIN (GENER11-ARIN ) > Admin GENER11-ARIN (GENER11-ARIN ) > Abuse GENER11-ARIN (GENER11-ARIN ) > > > It would be nice if ARIN would fix the command line whois server, but so far, my efforts to get them to do so have been fruitless. > > Owen > >> On Feb 26, 2015, at 4:01 AM, Mike Smith > wrote: >> >> Hi >> >> Please see below, anyone else can help test both DB and see the inconsistency? >> >> >> Carels-Air:~ carel$ whois 45.195.0.0 >> >> # >> # ARIN WHOIS data and services are subject to the Terms of Use >> # available at: https://www.arin.net/whois_tou.html >> # >> # If you see inaccuracies in the results, please report at >> # http://www.arin.net/public/whoisinaccuracy/index.xhtml >> # >> >> >> # >> # Query terms are ambiguous. The query is assumed to be: >> # "n 45.195.0.0" >> # >> # Use "?" to get help. >> # >> >> No match found for 45.195.0.0. >> >> >> >> >> # >> # ARIN WHOIS data and services are subject to the Terms of Use >> # available at: https://www.arin.net/whois_tou.html >> # >> # If you see inaccuracies in the results, please report at >> # http://www.arin.net/public/whoisinaccuracy/index.xhtml >> # >> >> Carels-Air:~ carel$ whois -h whois.afrinic.net 45.1950.0 >> % This is the AfriNIC Whois server. >> >> % Note: this output has been filtered. >> % To receive output for a database update, use the "-B" flag. >> >> % Information related to '45.192.0.0 - 45.199.255.255' >> >> % No abuse contact registered for 45.192.0.0 - 45.199255.255 >> >> inetnum: 45.192.0.0 - 45.199.255.255 >> netname: CloudInnovation >> descr: CloudInnovation infrastructure >> country: ZA >> admin-c: OS9-AFRINIC >> tech-c: OS9-AFRINIC >> status: ASSIGNED PA >> mnt-by: CIL1-MNT >> mnt-routes: CIL1-MNT >> source: AFRINIC # Filtered >> parent: 45.192.0.0 - 45.207.255.255 >> >> person: OutsideHeaven Support >> nic-hdl: OS9-AFRINIC >> address: Ebene >> address: MU >> address: Mahe >> address: Seychelles >> phone: +248 4 610 795 >> source: AFRINIC # Filtered >> >> >> On Thursday, February 26, 2015, John Curran > wrote: >> On Feb 26, 2015, at 2:23 AM, Mike Smith > wrote: >>> >>> Hi >>> >>> I have been told by your Hostmaster it has been resolved, however, equiriy to Whois.afrinic.net or Whois.arin.net still shows different results. >>> >>> Example would be 45.208.0.0, anyone can try. >> >> Mike - >> >> ARIN administers the 45/8 address block; there are specific subranges that are >> allocated to various RIRs, e.g. 45.192.0.0 - 45.222.255.255 to AFRINIC. You >> will this reflected in your Whois query results. >> >> Thanks, >> /John >> >> John Curran >> President and CEO >> ARIN >> >> >> >> _______________________________________________ >> 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 narten at us.ibm.com Fri Feb 27 00:53:02 2015 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 27 Feb 2015 00:53:02 -0500 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201502270553.t1R5r2NX008917@rotala.raleigh.ibm.com> Total of 44 messages in the last 7 days. script run at: Fri Feb 27 00:53:01 EST 2015 Messages | Bytes | Who --------+------+--------+----------+------------------------ 18.18% | 8 | 16.20% | 93523 | ms258322 at gmail.com 13.64% | 6 | 10.88% | 62812 | jcurran at arin.net 6.82% | 3 | 17.32% | 100023 | owen at delong.com 4.55% | 2 | 13.66% | 78887 | adudek16 at gmail.com 11.36% | 5 | 6.66% | 38453 | info at arin.net 6.82% | 3 | 5.93% | 34240 | mueller at syr.edu 6.82% | 3 | 3.91% | 22553 | jlewis at lewis.org 4.55% | 2 | 2.62% | 15100 | sethm at rollernet.us 2.27% | 1 | 3.46% | 19982 | athompso at athompso.net 2.27% | 1 | 2.84% | 16412 | stephen at sprunk.org 2.27% | 1 | 2.45% | 14130 | leo.vegoda at icann.org 2.27% | 1 | 2.10% | 12152 | cja at daydream.com 2.27% | 1 | 1.95% | 11242 | hannigan at gmail.com 2.27% | 1 | 1.92% | 11067 | rjletts at uw.edu 2.27% | 1 | 1.52% | 8792 | farmer at umn.edu 2.27% | 1 | 1.52% | 8763 | christopher.morrow at gmail.com 2.27% | 1 | 1.52% | 8750 | alh-ietf at tndh.net 2.27% | 1 | 1.26% | 7288 | andrew.dul at quark.net 2.27% | 1 | 1.23% | 7073 | narten at us.ibm.com 2.27% | 1 | 1.06% | 6103 | gary.buhrmaster at gmail.com --------+------+--------+----------+------------------------ 100.00% | 44 |100.00% | 577345 | Total