From gert at space.net Sat May 2 17:06:29 2015 From: gert at space.net (Gert Doering) Date: Sat, 2 May 2015 17:06:29 +0200 Subject: [address-policy-wg] Agenda for Amsterdam, draft v2 Message-ID: <20150502150629.GF54385@Space.Net> Hi APWG folks, RIPE meeting orga, below you can find a new draft for the RIPE address policy WG meeting's agenda, which will take place in Amsterdam in the following time slots: Wednesday, May 13, 09:00 - 10:30 Wednesday, May 13, 11:00 - 12:30 If you have anything else you want to see on the agenda, or if we need to change anything, please let us know. So far, the agenda is fairly light - if you have something you want to address, or that bothers you, let us know and we make room for you :-) The distribution of items to the two timeslot is somewhat subject to the time spent on discussion - but we'll try to stick to what's published. regards, Gert Doering, APWG chair ---------------------------------------------------------------------- Wednesday, 09:00-10:30 ---------------------------------------------------------------------- A. Administrative Matters 5 min (welcome, thanking the scribe, approving the minutes, etc.) B. WG Chair Selection [15 min?] - longest-serving chair (Gert Doering) stepping down - willing to be re-appointed and serve another term C. Current Policy Topics - Marco Schmidt, NCC PDO [15-20 min] - global policy overview "what's going on?" - common policy topics in all regions (end of IPv4, transfers, ...) - overview over concluded proposals in the RIPE region since RIPE69 2014-04 Removing IPv6 Requirement for Receiving Space from the Final /8 (consensus, policy) 2014-05 Policy for Inter-RIR Transfers of Internet Resources (consensus, policy) 2014-07 Language Clarification 2014-08 Language Clarification 2014-10 Language Clarification 2014-11 Language Clarification (consensus, policy) 2014-09 Language Clarification in "IPv6 Address Space for IXPs" **no consensus, withdrawn** 2014-12 Allow IPv6 Transfers (consensus, policy) 2014-13 Allow AS Number Transfers (consensus, policy) - brief overview over new proposals (if any) D. Feedback From NCC Registration Service - Andrea Cima (NCC RS) [30-40 min] (+ discussion with the group) F. Discussion of open policy proposals [10-30 min] 2014-03 Remove Multihoming Requirement for AS Number .. (Job Snijders - no discussion, just status update from the WG chair) 2015-01 Alignment of Transfer Requirements for IPv4 Allocations (Elvis Velea) [some bits might get moved to "after coffee break" if we run out of time] ---------------------------------------------------------------------- Wednesday, 11:00-12:30 ---------------------------------------------------------------------- Welcome back H. Will It Be Routed? - On IPv6 Address Space Allocation & Assignment [30 m] Approaches in Very Large Organizations Presentation by Enno Rey, and Discussion F. Discussion of open policy proposals (continued) [45 min?] 2015-02 Keep IPv6 PI When Requesting IPv6 Allocation (James Kennedy) 2015-03 Assignment Criteria for IPv6 Initial Allocation Size (Mathew Newton, Alexander Brinkmann) G. New Ideas under Discussion [15 min] - Elvis Daniel Velea - change size of last /22 allocations - Erik Bais - unified transfer policy Y. Open Policy Hour "The Open Policy Hour (OPH) is a showcase for your policy ideas. If you have a policy proposal you'd like to debut, prior to formally submitting it, here is your opportunity." Z. AOB -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From andreas.larsen at ip-only.se Mon May 4 08:44:30 2015 From: andreas.larsen at ip-only.se (Andreas Larsen) Date: Mon, 4 May 2015 06:44:30 +0000 Subject: [address-policy-wg] 2014-03 Review Period extended until 19 May 2015 (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: References: Message-ID: <0036CB07-44FB-418D-A44E-B4E4511B2580@ip-only.se> Support +1 for this Den 2015-04-28 08:33 skrev Carlos Friacas : > > >Support. +1. > >I've read the "Arguments opposing the proposal", and i don't believe >fragmentation will significantly increase as a result of this policy. > >Anyway some people already fragment more than they should... :-) > > >Regards, >Carlos > > >On Mon, 9 Mar 2015, Marco Schmidt wrote: > >> >> Dear colleagues, >> >> >> The Review Period for the proposal 2014-03, "Remove Multihoming Requirement for >> AS Number Assignments" has been extended until 19 May 2015. >> >> >> You can find the full proposal at: >> >> https://www.ripe.net/ripe/policies/proposals/2014-03 >> >> >> We encourage you to review this policy proposal and send your comments >> to . >> >> Regards, >> >> Marco Schmidt >> Policy Development Officer >> RIPE NCC >> > From mtl at netassist.ua Fri May 1 20:18:59 2015 From: mtl at netassist.ua (Max Tulyev) Date: Fri, 01 May 2015 21:18:59 +0300 Subject: [address-policy-wg] Hoarding /22 out of 185/8 In-Reply-To: References: <553EF9E6.8020907@init7.net> <1146891946.20150428081321@infinitytelecom.ro> <553F1ACB.6090201@kebab.org.pl> <20150428075234.16d44154@echo.ms.redpill-linpro.com> Message-ID: <5543C393.2030000@netassist.ua> On 28.04.15 15:02, Alex Le Heux wrote: > Alternatively, members could petition the RIPE NCC board to raise the New > LIR sign-up fee to 10 or 15 times the current level. That should stop this > in its tracks as well and would still not be a huge barrier to new > entrants. Not 10-20-30-40 times, but up to cost of buying /22 on the market, which is about $10k. From tom at kebab.org.pl Mon May 4 13:50:12 2015 From: tom at kebab.org.pl (Tomasz SLASKI) Date: Mon, 04 May 2015 13:50:12 +0200 Subject: [address-policy-wg] Hoarding /22 out of 185/8 In-Reply-To: <5543C393.2030000@netassist.ua> References: <553EF9E6.8020907@init7.net> <1146891946.20150428081321@infinitytelecom.ro> <553F1ACB.6090201@kebab.org.pl> <20150428075234.16d44154@echo.ms.redpill-linpro.com> <5543C393.2030000@netassist.ua> Message-ID: <55475CF4.2040206@kebab.org.pl> W dniu 2015-05-01 o 20:18, Max Tulyev pisze: > On 28.04.15 15:02, Alex Le Heux wrote: >> Alternatively, members could petition the RIPE NCC board to raise the New >> LIR sign-up fee to 10 or 15 times the current level. That should stop this >> in its tracks as well and would still not be a huge barrier to new >> entrants. > Not 10-20-30-40 times, but up to cost of buying /22 on the market, which > is about $10k. > > $10k for /22 is the speculative price of 'virgin space' offered for spammers, who buy /22 and then burn it out on every blacklist in the World, making the addresses practically unusable for long time. Who havinghealthy brain is buying /22 for $10k, for 'normal' purposes, if he can buy with no questions /22 by just opening a new LIR? -- Tomasz ?l?ski tom at kebab.org.pl From richih.mailinglist at gmail.com Mon May 4 14:09:18 2015 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Mon, 4 May 2015 14:09:18 +0200 Subject: [address-policy-wg] Hoarding /22 out of 185/8 In-Reply-To: <553FC851.9030905@list.ak.cx> References: <553EF9E6.8020907@init7.net> <1146891946.20150428081321@infinitytelecom.ro> <553F1ACB.6090201@kebab.org.pl> <20150428075234.16d44154@echo.ms.redpill-linpro.com> <553F95E6.9060006@walcz.net> <553FC56E.3080204@opteamax.de> <553FC851.9030905@list.ak.cx> Message-ID: On Tue, Apr 28, 2015 at 7:50 PM, Andre Keller wrote: > In our case (which did not involve networks from the last /8) we were > taking over the whole infrastructure from a datacenter site of the > former LIR, but did not have an agreement that specifically said so. So > we made an additional agreement to fulfill the RIPE NCCs request. So do > you really think it is hard to provide such documentation, even if you > did not really take over some equipment and/or customers? We also took over a DC along with a LIR some time ago. While the process was somewhat tedious and while we had to revisit several documents due to arbitrary bureaucracy, it would have been trivial to do the same in a malicious way. And if you don't believe me that RichiH-a didn't properly take over RichiH-b, I am sure their customer RichiH-c would be happy to provide a letter stating how desperately they need exactly _that_ IP space. I honestly don't know what we could do to improve the situation, but ru.ibulavkin* seems to be _clearly_ abusing the system. The sad part is, I am only surprised by the fact that it took so long. Richard From mail at danrl.de Mon May 4 17:51:46 2015 From: mail at danrl.de (=?utf-8?Q?Dan_L=C3=BCdtke?=) Date: Mon, 4 May 2015 17:51:46 +0200 Subject: [address-policy-wg] Hoarding /22 out of 185/8 In-Reply-To: <553EF9E6.8020907@init7.net> References: <553EF9E6.8020907@init7.net> Message-ID: <12DAE43E-B91E-4E3E-A1C9-0E2E1F66C81C@danrl.de> > I thought to make the working group aware. Great, finally IPv4 is becoming a market so hot, that deploying IPv6 seems to be the better option. I would like to see more like this, let them battle for the last bites of the cadaver. Good to know that ru.ibulavkin25 has at least 3 /32. They sure will be able to serve the endpoints they deploy the tiny bit of legacy IP space they have using IPv6, too. Dan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: Message signed with OpenPGP using GPGMail URL: From silvia.hagen at sunny.ch Mon May 4 20:11:15 2015 From: silvia.hagen at sunny.ch (Silvia Hagen) Date: Mon, 4 May 2015 18:11:15 +0000 Subject: [address-policy-wg] Hoarding /22 out of 185/8 In-Reply-To: <12DAE43E-B91E-4E3E-A1C9-0E2E1F66C81C@danrl.de> References: <553EF9E6.8020907@init7.net> <12DAE43E-B91E-4E3E-A1C9-0E2E1F66C81C@danrl.de> Message-ID: Reminds me of the old joke that IPv4 will never run out, because nobody will be able to afford that last IPv4 address :-) -----Urspr?ngliche Nachricht----- Von: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] Im Auftrag von Dan L?dtke Gesendet: Montag, 4. Mai 2015 17:52 An: address-policy-wg at ripe.net Betreff: Re: [address-policy-wg] Hoarding /22 out of 185/8 > I thought to make the working group aware. Great, finally IPv4 is becoming a market so hot, that deploying IPv6 seems to be the better option. I would like to see more like this, let them battle for the last bites of the cadaver. Good to know that ru.ibulavkin25 has at least 3 /32. They sure will be able to serve the endpoints they deploy the tiny bit of legacy IP space they have using IPv6, too. Dan From hamed at skydsl.ir Tue May 5 16:15:02 2015 From: hamed at skydsl.ir (Hamed Shafaghi) Date: Tue, 5 May 2015 18:45:02 +0430 Subject: [address-policy-wg] 2014-03 Review Period extended until 19 May 2015 (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: References: Message-ID: +1 Strongly support. -- -------------------------------------------- I Hamed Shafaghi I I Managing Director I I Skydsl? Telecom I hamed at skydsl.ir I www.skydsl.ir I -------------- next part -------------- An HTML attachment was scrubbed... URL: From president at ukraine.su Tue May 5 16:04:52 2015 From: president at ukraine.su (Max Tulyev) Date: Tue, 05 May 2015 17:04:52 +0300 Subject: [address-policy-wg] Hoarding /22 out of 185/8 In-Reply-To: <55475CF4.2040206@kebab.org.pl> References: <553EF9E6.8020907@init7.net> <1146891946.20150428081321@infinitytelecom.ro> <553F1ACB.6090201@kebab.org.pl> <20150428075234.16d44154@echo.ms.redpill-linpro.com> <5543C393.2030000@netassist.ua> <55475CF4.2040206@kebab.org.pl> Message-ID: <5548CE04.4080605@ukraine.su> Yes, that's the price of *clean* IPv4 /22 on the market, without any trackable criminal history. Yes, spammers *can* register a new LIR for /22. And I believe they (or somebody for them) *do* that. No, people buy clean /22 *not* only for sendind spam. Good business want good IPs and wish to pay some money for that. BUT, some good companies don't want/can't start-up a horde of LIRs using a horde of shell companies, and /22 is as small as not visible for them. They need /16 for example, and wish to pay some money for On 04.05.15 14:50, Tomasz SLASKI wrote: > $10k for /22 is the speculative price of 'virgin space' offered for > spammers, who buy /22 and then burn it out on every blacklist in the > World, making the addresses practically unusable for long time. Who > havinghealthy brain is buying /22 for $10k, for 'normal' purposes, if he > can buy with no questions /22 by just opening a new LIR? From mtl at netassist.ua Tue May 5 16:04:12 2015 From: mtl at netassist.ua (Max Tulyev) Date: Tue, 05 May 2015 17:04:12 +0300 Subject: [address-policy-wg] Hoarding /22 out of 185/8 In-Reply-To: <55475CF4.2040206@kebab.org.pl> References: <553EF9E6.8020907@init7.net> <1146891946.20150428081321@infinitytelecom.ro> <553F1ACB.6090201@kebab.org.pl> <20150428075234.16d44154@echo.ms.redpill-linpro.com> <5543C393.2030000@netassist.ua> <55475CF4.2040206@kebab.org.pl> Message-ID: <5548CDDC.9040205@netassist.ua> Yes, that's the price of *clean* IPv4 /22 on the market, without any trackable criminal history. Yes, spammers *can* register a new LIR for /22. And I believe they (or somebody for them) *do* that. No, people buy clean /22 *not* only for sendind spam. Good business want good IPs and wish to pay some money for that. BUT, some good companies don't want/can't start-up a horde of LIRs using a horde of shell companies, and one /22 is as small as not visible for them. They need /16 for example, and wish to pay some money for just buying a network. The price I know is from $6 to $15 per IP. That's the source of that hoarding /22 business. If you want to eliminate it really - the only real way is to kill a profit. On 04.05.15 14:50, Tomasz SLASKI wrote: > $10k for /22 is the speculative price of 'virgin space' offered for > spammers, who buy /22 and then burn it out on every blacklist in the > World, making the addresses practically unusable for long time. Who > havinghealthy brain is buying /22 for $10k, for 'normal' purposes, if he > can buy with no questions /22 by just opening a new LIR? From aleksbulgakov at gmail.com Wed May 6 08:53:21 2015 From: aleksbulgakov at gmail.com (Aleksey Bulgakov) Date: Wed, 6 May 2015 09:53:21 +0300 Subject: [address-policy-wg] Hoarding /22 out of 185/8 In-Reply-To: <5548CDDC.9040205@netassist.ua> References: <553EF9E6.8020907@init7.net> <1146891946.20150428081321@infinitytelecom.ro> <553F1ACB.6090201@kebab.org.pl> <20150428075234.16d44154@echo.ms.redpill-linpro.com> <5543C393.2030000@netassist.ua> <55475CF4.2040206@kebab.org.pl> <5548CDDC.9040205@netassist.ua> Message-ID: What's wrong in /22 hoarding? How does it abuse the system? 06 ??? 2015 ?. 9:30 ???????????? "Max Tulyev" ???????: > Yes, that's the price of *clean* IPv4 /22 on the market, without any > trackable criminal history. > Yes, spammers *can* register a new LIR for /22. And I believe they (or > somebody for them) *do* that. > No, people buy clean /22 *not* only for sendind spam. Good business want > good IPs and wish to pay some money for that. > BUT, some good companies don't want/can't start-up a horde of LIRs using > a horde of shell companies, and one /22 is as small as not visible for > them. They need /16 for example, and wish to pay some money for just > buying a network. The price I know is from $6 to $15 per IP. > > That's the source of that hoarding /22 business. If you want to > eliminate it really - the only real way is to kill a profit. > > On 04.05.15 14:50, Tomasz SLASKI wrote: > > $10k for /22 is the speculative price of 'virgin space' offered for > > spammers, who buy /22 and then burn it out on every blacklist in the > > World, making the addresses practically unusable for long time. Who > > havinghealthy brain is buying /22 for $10k, for 'normal' purposes, if he > > can buy with no questions /22 by just opening a new LIR? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at kebab.org.pl Wed May 6 09:11:38 2015 From: tom at kebab.org.pl (Tomasz SLASKI) Date: Wed, 06 May 2015 09:11:38 +0200 Subject: [address-policy-wg] Hoarding /22 out of 185/8 In-Reply-To: References: <553EF9E6.8020907@init7.net> <1146891946.20150428081321@infinitytelecom.ro> <553F1ACB.6090201@kebab.org.pl> <20150428075234.16d44154@echo.ms.redpill-linpro.com> <5543C393.2030000@netassist.ua> <55475CF4.2040206@kebab.org.pl> <5548CDDC.9040205@netassist.ua> Message-ID: <5549BEAA.7090509@kebab.org.pl> W dniu 2015-05-06 o 08:53, Aleksey Bulgakov pisze: > > What's wrong in /22 hoarding? How does it abuse the system? > It's speeds-up the whole IPv4 depletion, and heats the speculative prices. IMO, the situation will continue as long as the IPv4 prices will be accepted by the market. After crossing the threshold of pain, people will notice that it is better to migrate to IPv6 instead of paying sick money for antiquitie numbers. Unfortunately, the pain threshold is very high, because there is still lot of equipment bought for millions $ that you have to throw to scrap dump, to say IPv4 goodbye permanently. Regards, -- Tomasz ?l?ski tom at kebab.org.pl From ripe-wgs at radu-adrian.feurdean.net Wed May 6 11:05:29 2015 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Wed, 06 May 2015 11:05:29 +0200 Subject: [address-policy-wg] Hoarding /22 out of 185/8 In-Reply-To: <5549BEAA.7090509@kebab.org.pl> References: <553EF9E6.8020907@init7.net> <1146891946.20150428081321@infinitytelecom.ro> <553F1ACB.6090201@kebab.org.pl> <20150428075234.16d44154@echo.ms.redpill-linpro.com> <5543C393.2030000@netassist.ua> <55475CF4.2040206@kebab.org.pl> <5548CDDC.9040205@netassist.ua> <5549BEAA.7090509@kebab.org.pl> Message-ID: <1430903129.2882374.263340629.4DDA117C@webmail.messagingengine.com> On Wed, May 6, 2015, at 09:11, Tomasz SLASKI wrote: > IMO, the situation will continue as long as the IPv4 prices will be > accepted by the market. After crossing the threshold of pain, people > will notice that it is better to migrate to IPv6 instead of paying sick > money for antiquitie numbers. Unfortunately, the pain threshold is very > high, because there is still lot of equipment bought for millions $ that > you have to throw to scrap dump, to say IPv4 goodbye permanently. Well, today the problem does NOT end with "deploy IPv6". An an ISP you still have to do CGN and in a number of countries conserve TCP/UDP connection logs for some time (12/24/36 months). No IPv4 at all = out of business. If you also do "enterprise access", you can't even start your business without IPv4 space. For server hosting providers, it's even worse, IPv6 being close to no help at all (you still need 1 public IPv4 per server sold, for the moment IPv6 doesn't help in any way - it is a longer-term solution, that for the monent only helps "the others"). Then yes, all that hardware that doesn't work without IPv4, but you still have "non-public" space for that as a last resort solution. An then there's all the small but numerous companies that will "never ever in hell" deploy anything if there is not explicit customer demand - and customers rarely make an explicit demand for IPv6, and when they do it's generally "1 in 1000". Point is, even for people that DO deploy IPv6, there is still a need of v4 adresses for quite some time. The "hit the wall hard, ASAP" strategy (like in ARIN or LACNIC land) doesn't seem to be the solution favoured by the community in RIPE-land. From ripe at opteamax.de Wed May 6 12:00:15 2015 From: ripe at opteamax.de (Opteamax GmbH - RIPE-Team) Date: Wed, 06 May 2015 12:00:15 +0200 Subject: [address-policy-wg] Hoarding /22 out of 185/8 In-Reply-To: <1430903129.2882374.263340629.4DDA117C@webmail.messagingengine.com> References: <553EF9E6.8020907@init7.net> <1146891946.20150428081321@infinitytelecom.ro> <553F1ACB.6090201@kebab.org.pl> <20150428075234.16d44154@echo.ms.redpill-linpro.com> <5543C393.2030000@netassist.ua> <55475CF4.2040206@kebab.org.pl> <5548CDDC.9040205@netassist.ua> <5549BEAA.7090509@kebab.org.pl> <1430903129.2882374.263340629.4DDA117C@webmail.messagingengine.com> Message-ID: <61ae5a1f8843df8f157ef2d008aef7bf@opteamax.de> Am 2015-05-06 11:05, schrieb Radu-Adrian FEURDEAN: > > Point is, even for people that DO deploy IPv6, there is still a need of > v4 adresses for quite some time. The "hit the wall hard, ASAP" strategy > (like in ARIN or LACNIC land) doesn't seem to be the solution favoured > by the community in RIPE-land. > And exactly this is the reason why the /22-policy is as it is and is not meant to be bypassed by setting up LIRs and transfering. Even if your "default" is IPv6, you'll need at least this few IPv4 to be able to run CGN etc. I just had this mail (below) in my ticketsystem > Hello. > > As you know, the RIPE NCC can only provide one final /22 to your LIR > because it is currently allocating address space from the last /8 of > IPv4 addresses. > > However the RIPE NCC allows to get IPv4 addresses from other LIR. Our > company has LIR status and ready to transfer such addresses to your > LIR. This operation is approved by the RIPE NCC and absolutely legal. > > The blocks are absolutely clean, haven't been in usage, are absent in > any blacklist. > > If you have any questions, don't hesitate to ask me. Simply answer to > this letter and you will get the answer shortly. ... and reading this I think the policy must be strictly changed. I do not exactly know the wording of RIPE membership rules, but if you set up a "Verein" in Germany (and this is more or less the type which matches best the legal form RIPE NCC has) you are recommended to put something like "each and every person who is willingly doing any harm to the club, it's reputation or other members is to be kicked out without any right for compensations. All rights this person has be being member are immediately withdrawn. The exclusion from the club does not reduce the any regress against the excluded member". I see, that it is not possible to prevent every bypassing, but I think someone who is even spaming and advertising sale of resources shall be kicked out RIPE NCC immediately and all resources this person or enterprise ever requested should be withdrawn! I am not saying that people opening a second LIR and later merges this second LIR back after a while for which ever reason (e.g. second LIRs purpose did not launch successfully) should not be hit by this rule; sometimes plans don't work out. But if it is obviously that someone is doing it "regualary" this IS obviously and can be seen easily by membership application and here we absolutely should stop the abuse. BR Jens From michele at blacknight.com Wed May 6 11:52:47 2015 From: michele at blacknight.com (Michele Neylon - Blacknight) Date: Wed, 6 May 2015 09:52:47 +0000 Subject: [address-policy-wg] Hoarding /22 out of 185/8 In-Reply-To: <5549BEAA.7090509@kebab.org.pl> References: <553EF9E6.8020907@init7.net> <1146891946.20150428081321@infinitytelecom.ro> <553F1ACB.6090201@kebab.org.pl> <20150428075234.16d44154@echo.ms.redpill-linpro.com> <5543C393.2030000@netassist.ua> <55475CF4.2040206@kebab.org.pl> <5548CDDC.9040205@netassist.ua> <5549BEAA.7090509@kebab.org.pl> Message-ID: <826A22E7-7CDA-42B7-B7AE-DA49DFB42138@blacknight.com> On 06/05/2015 08:11, "Tomasz SLASKI" wrote: > >IMO, the situation will continue as long as the IPv4 prices will be >accepted by the market. After crossing the threshold of pain, people >will notice that it is better to migrate to IPv6 instead of paying sick >money for antiquitie numbers. Unfortunately, the pain threshold is very >high, because there is still lot of equipment bought for millions $ that >you have to throw to scrap dump, to say IPv4 goodbye permanently. Tomasz Until the major ISPs start turning on IPv6 this is going to be a ?chicken and egg? scenario I asked all the large Irish ISPs what they were doing and they essentially said they had enough IPv4 space so they didn?t see any need to switch on IPv6 *sigh* Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains http://www.blacknight.host/ http://blog.blacknight.com/ http://www.blacknight.press - get our latest news & media coverage http://www.technology.ie Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Social: http://mneylon.social Random Stuff: http://michele.irish ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From ripe-wgs at radu-adrian.feurdean.net Wed May 6 11:58:25 2015 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Wed, 06 May 2015 11:58:25 +0200 Subject: [address-policy-wg] Hoarding /22 out of 185/8 In-Reply-To: <61ae5a1f8843df8f157ef2d008aef7bf@opteamax.de> References: <553EF9E6.8020907@init7.net> <1146891946.20150428081321@infinitytelecom.ro> <553F1ACB.6090201@kebab.org.pl> <20150428075234.16d44154@echo.ms.redpill-linpro.com> <5543C393.2030000@netassist.ua> <55475CF4.2040206@kebab.org.pl> <5548CDDC.9040205@netassist.ua> <5549BEAA.7090509@kebab.org.pl> <1430903129.2882374.263340629.4DDA117C@webmail.messagingengine.com> <61ae5a1f8843df8f157ef2d008aef7bf@opteamax.de> Message-ID: <1430906305.2895673.263361445.7F215455@webmail.messagingengine.com> On Wed, May 6, 2015, at 12:00, Opteamax GmbH - RIPE-Team wrote: > ... and reading this I think the policy must be strictly changed. I do > not exactly know the wording of RIPE membership rules, but if you set up > a "Verein" in Germany (and this is more or less the type which matches > best the legal form RIPE NCC has) you are recommended to put something > like "each and every person who is willingly doing any harm to the club, > it's reputation or other members is to be kicked out without any right > for compensations. All rights this person has be being member are > immediately withdrawn. The exclusion from the club does not reduce the > any regress against the excluded member". Except this is not policy (done by the RIPE community), but a RIPE NCC affair. Changes like this are to be decided in general meeting with approval from a majority of members (including the incriminated LIRs and people that may not understand what this is all about). Discussing such issues shoud be done ont the APWG mailing list, but on the members-discuss or a membership-related mailing list. Please also take into account that people having a right to vote at the NCC GM are not always the same as the ones active here. But the idea is not bad. > I see, that it is not possible to prevent every bypassing, but I think > someone who is even spaming and advertising sale of resources shall be > kicked out RIPE NCC immediately and all resources this person or > enterprise ever requested should be withdrawn! For the time being it is a little difficult to enforce, and will yield some highly undesirable consequences. From ibulavkin at gmail.com Wed May 6 12:44:02 2015 From: ibulavkin at gmail.com (Ivan Bulavkin) Date: Wed, 6 May 2015 13:44:02 +0300 Subject: [address-policy-wg] Hoarding /22 out of 185/8 Message-ID: > ... and reading this I think the policy must be strictly changed. I do > not exactly know the wording of RIPE membership rules, but if you set up > a "Verein" in Germany (and this is more or less the type which matches > best the legal form RIPE NCC has) you are recommended to put something > like "each and every person who is willingly doing any harm to the club, > it's reputation or other members is to be kicked out without any right > for compensations. All rights this person has be being member are > immediately withdrawn. The exclusion from the club does not reduce the > any regress against the excluded member". > Except this is not policy (done by the RIPE community), but a RIPE NCC > affair. Changes like this are to be decided in general meeting with > approval from a majority of members (including the incriminated LIRs and > people that may not understand what this is all about). > Discussing such issues shoud be done ont the APWG mailing list, but on > the members-discuss or a membership-related mailing list. > Please also take into account that people having a right to vote at the > NCC GM are not always the same as the ones active here. > But the idea is not bad. > I see, that it is not possible to prevent every bypassing, but I think > someone who is even spaming and advertising sale of resources shall be > kicked out RIPE NCC immediately and all resources this person or > enterprise ever requested should be withdrawn! In 2010, 2011, 2012 I was just a LIR client (I didn't have my own registered LIR) : I asked the LIR for IPv4 assignment and got it. The cost for /21 IPv4 assignment was 300 USD/year. I got some /21 assignments from one LIR, some /21 from another LIRs and all were - ok: the price was good for me, I used the PA space from LIR allocation (as RIPE NCC recommended and didn't ask for PI IPv4). On June 2012, I received a letter from my LIR that says: the price for PA assignment /21 from January 2013 will 24000 USD/year. The another LIRs increased price for PA IPv4, but no so dramatically. I had to find a replacement for address space with a crazy price that affected the clients. So we can see the following: 1) Client asked the LIR for IPv4, and the LIR recommends the PA IPv4 assignment from their allocation; 2) The LIR asked the RIPE NCC for new allocation for clients and got more and more allocations; 3) The RIPE NCC didn't control the price for IPv4 for LIR clients; 3.1) I'm sure, the RIPE NCC shall not approved the PI IPv4 assignment for me with reason: I'm not sure that a RIPE NCC member (LIR) will not increase drastically the prices. 4) One day the LIR drastically increase the price for PA IPv4 for end users from 300 USD/year to 24000 USD/year and the multiple PA allocations are ready for sell... 5) The RIPE NCC policies didn't allow me to register the my own LIR and picked up the PA allocation from crazy LIR: pay or close your business, or get only /22. 6) The RIPE NCC is approved the "selling" the IPv4 from last /8 on 23/01/2013 - it is good for any existing and new LIR to get /22 that LIR really don't need and sell it for 10$/IP. 7.1) The RIPE NCC is approving selling the IPv4 from 185/8 for 2 years and there is no reaction from RIPE NCC community, only now. 7.2) So why do I need to pay 15$/IP or more to the LIR from my real history or to any existing LIR from 185/8? P.S. Maybe someone who speaks the most about saving 185/8 and has reserves of IPv4 is ready to transfer them to me for free, because they had previously received them from RIPE for free? I think I know in advance the answer to this rhetorical question. Best regards, Ivan Bulavkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From John.Collins at BIT.admin.ch Wed May 6 13:41:15 2015 From: John.Collins at BIT.admin.ch (John.Collins at BIT.admin.ch) Date: Wed, 6 May 2015 11:41:15 +0000 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) Message-ID: <5D23C81DA72B5A4CACB3B12075F7B347D7E4A9BD@SB00112A.adb.intra.admin.ch> Hi all, speaking for the LIR requesting IPv6 space for the government authorities in Switzerland I support the proposed policy change. Whereas the existing policy wording promotes a non-wasteful use of addresses, it prevents the implementation of addressing plans that are aligned with federated organisational structures where the principle of subsidiarity is followed and members are highly autonomous. Such addressing plans may be required in large organisations or federations of autonomous states, which in addition to membership of the containing whole, may require autonomous routing and addressing plans. kind regards, John Collins ch.swissgov FOITT An IT Service Provider of the Swiss Federal Administration -------------- next part -------------- An HTML attachment was scrubbed... URL: From mir at ripe.net Wed May 6 16:32:04 2015 From: mir at ripe.net (Mirjam Kuehne) Date: Wed, 06 May 2015 16:32:04 +0200 Subject: [address-policy-wg] New on RIPE Labs: IPv4 Transfers in the RIPE NCC Service Region Message-ID: <554A25E4.7060108@ripe.net> Dear colleagues, Now that the RIPE NCC has reached its last /8, some Local Internet Registries (LIRs) are choosing to obtain additional address space from other organisations via the emerging transfer market. In this new article on RIPE Labs we examine statistics from the last two and a half years of transfers and visualise per country aggregates on a map: https://labs.ripe.net/Members/wilhelm/ipv4-transfers-in-the-ripe-ncc-service-region Kind regards, Mirjam Kuehne RIPE NCC From LIR at bva.bund.de Thu May 7 11:56:58 2015 From: LIR at bva.bund.de (LIR (BIT I 5)) Date: Thu, 7 May 2015 09:56:58 +0000 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: References: Message-ID: Hello, I agree with this opinion. Therefore: +1 Carsten LIR de.government -----Urspr?ngliche Nachricht----- Von: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] Im Auftrag von James Blessing Gesendet: Dienstag, 28. April 2015 14:20 An: Address Policy Working Group Betreff: Re: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) On 28 April 2015 at 13:00, Marco Schmidt wrote: > > > The proposal aims to expand the criteria for evaluating initial IPv6 allocations larger than a /29. The RIPE NCC would consider additional aspects beyond only the number of existing users and extent of the organisation's infrastructure. > https://www.ripe.net/participate/policies/proposals/2015-03 Support at current stage - may change after seeing IA J -- James Blessing 07989 039 476 From carlosf.gomez at seap.minhap.es Thu May 7 17:32:32 2015 From: carlosf.gomez at seap.minhap.es (=?windows-1252?Q?Carlos_G=F3mez_Mu=F1oz?=) Date: Thu, 07 May 2015 17:32:32 +0200 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: <5D23C81DA72B5A4CACB3B12075F7B347D7E4A9BD@SB00112A.adb.intra.admin.ch> References: <5D23C81DA72B5A4CACB3B12075F7B347D7E4A9BD@SB00112A.adb.intra.admin.ch> Message-ID: <554B8590.8020702@seap.minhap.es> Dear all, We, seap.es, the LIR requesting IPv6 space for the government authorities in Spain, are facing the same problem as Switzerland. Therefore, I support the proposed policy change. Best regards, *Carlos G?mez Mu?oz * /Directorate for Information and Communication Technologies Ministry of Finance and Public Administrations / El 06/05/2015 a las 13:41, John.Collins at BIT.admin.ch escribi?: > > Hi all, > > speaking for the LIR requesting IPv6 space for the government > authorities in Switzerland I support the proposed policy change. > Whereas the existing policy wording promotes a non-wasteful use of > addresses, it prevents the implementation of addressing plans that are > aligned with federated organisational structures where the principle > of subsidiarity is followed and members are highly autonomous. Such > addressing plans may be required in large organisations or federations > of autonomous states, which in addition to membership of the > containing whole, may require autonomous routing and addressing plans. > > kind regards, > > John Collins > > ch.swissgov > > FOITT > > An IT Service Provider of the Swiss Federal Administration > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ip at infinitytelecom.ro Thu May 7 20:04:13 2015 From: ip at infinitytelecom.ro (Infinity Telecom SRL) Date: Thu, 7 May 2015 21:04:13 +0300 Subject: [address-policy-wg] New on RIPE Labs: IPv4 Transfers in the RIPE NCC Service Region In-Reply-To: <554A25E4.7060108@ripe.net> References: <554A25E4.7060108@ripe.net> Message-ID: <895536294.20150507210413@infinitytelecom.ro> Hello Mirjam, Someone made a comment on this article from the RIPE Labs. The guy said: "He has earned more than 4millions USD for selling his IPs." I am just speechless.. if its true. -- Best regards, Gabriel Voitis -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at danrl.de Fri May 8 11:31:31 2015 From: mail at danrl.de (=?utf-8?Q?Dan_L=C3=BCdtke?=) Date: Fri, 8 May 2015 11:31:31 +0200 Subject: [address-policy-wg] New on RIPE Labs: IPv4 Transfers in the RIPE NCC Service Region In-Reply-To: <895536294.20150507210413@infinitytelecom.ro> References: <554A25E4.7060108@ripe.net> <895536294.20150507210413@infinitytelecom.ro> Message-ID: See, we can not win this games. Let?s stop wasting energy and resources on dealing with legacy IP and how to make it work for a bit longer. New entrants are entering are market that is not fair, and we can not make a real difference. The only way forward is to push IPv6 and restore a healthy climate regarding the availability of IP addresses. 4m is nice, though. Should be above average... > On 7 May 2015, at 20:04, Infinity Telecom SRL wrote: > > Hello Mirjam, > > > Someone made a comment on this article from the RIPE Labs. > > The guy said: "He has earned more than 4millions USD for selling his IPs." > > I am just speechless.. if its true. > > > > -- > Best regards, > Gabriel Voitis From sebastian at karotte.org Fri May 8 13:54:14 2015 From: sebastian at karotte.org (Sebastian Wiesinger) Date: Fri, 8 May 2015 13:54:14 +0200 Subject: [address-policy-wg] New on RIPE Labs: IPv4 Transfers in the RIPE NCC Service Region In-Reply-To: References: <554A25E4.7060108@ripe.net> <895536294.20150507210413@infinitytelecom.ro> Message-ID: <20150508115414.GA23553@danton.fire-world.de> * Dan L?dtke [2015-05-08 11:33]: > See, we can not win this games. Let?s stop wasting energy and > resources on dealing with legacy IP and how to make it work for a > bit longer. New entrants are entering are market that is not fair, > and we can not make a real difference. The only way forward is to > push IPv6 and restore a healthy climate regarding the availability > of IP addresses. Dan, if you don't want to invest your time trying to make this market more fair by all means go ahead and do something else. There are still people here who would like to try so that new players can enter a market that will be dominated by IPv4 for some time to come. Most people here are pushing IPv6 but as much as you want to bury IPv4 it will still be around for some time. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 616 bytes Desc: Digital signature URL: From remco.vanmook at gmail.com Fri May 8 15:40:44 2015 From: remco.vanmook at gmail.com (remco van mook) Date: Fri, 08 May 2015 13:40:44 +0000 Subject: [address-policy-wg] New on RIPE Labs: IPv4 Transfers in the RIPE NCC Service Region In-Reply-To: <20150508115414.GA23553@danton.fire-world.de> References: <554A25E4.7060108@ripe.net> <895536294.20150507210413@infinitytelecom.ro> <20150508115414.GA23553@danton.fire-world.de> Message-ID: Three years and one day ago, I wrote on this very list: "...Personally I'm rather sick and tired of hearing people say 'yes, let's break IPv4 so we all MUST move to IPv6'. If you think this is good policy or even good engineering, please think again. It will make us end up with a broken internet that, surprise, we won't be managing any more. Breaking IPv4 might lead to increased IPv6 adoption, but not on the internet as we know it today. Everybody who wants to connect his organisation to the internet is going to need at least some IPv4 address space for the time being, so why screw it up for new entrants?..." Whether this is about reinventing final /8 or about people making money on IPv4 transfers does not make one jot of a difference. Remco (no hats) On Fri, May 8, 2015 at 1:54 PM Sebastian Wiesinger wrote: > * Dan L?dtke [2015-05-08 11:33]: > > See, we can not win this games. Let?s stop wasting energy and > > resources on dealing with legacy IP and how to make it work for a > > bit longer. New entrants are entering are market that is not fair, > > and we can not make a real difference. The only way forward is to > > push IPv6 and restore a healthy climate regarding the availability > > of IP addresses. > > Dan, > > if you don't want to invest your time trying to make this market more > fair by all means go ahead and do something else. There are still > people here who would like to try so that new players can enter a > market that will be dominated by IPv4 for some time to come. > > Most people here are pushing IPv6 but as much as you want to bury IPv4 > it will still be around for some time. > > Regards > > Sebastian > > -- > GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) > 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE > SCYTHE. > -- Terry Pratchett, The Fifth Elephant > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marty at akamai.com Fri May 8 18:59:03 2015 From: marty at akamai.com (Hannigan, Martin) Date: Fri, 8 May 2015 16:59:03 +0000 Subject: [address-policy-wg] New on RIPE Labs: IPv4 Transfers in the RIPE NCC Service Region In-Reply-To: References: <554A25E4.7060108@ripe.net> <895536294.20150507210413@infinitytelecom.ro> <20150508115414.GA23553@danton.fire-world.de> Message-ID: <3BDA1D6C-D32C-44B7-971F-A0A3DDE89DB0@akamai.com> +1 Best, -M< On May 8, 2015, at 9:40 AM, remco van mook > wrote: Three years and one day ago, I wrote on this very list: "...Personally I'm rather sick and tired of hearing people say 'yes, let's break IPv4 so we all MUST move to IPv6'. If you think this is good policy or even good engineering, please think again. It will make us end up with a broken internet that, surprise, we won't be managing any more. Breaking IPv4 might lead to increased IPv6 adoption, but not on the internet as we know it today. Everybody who wants to connect his organisation to the internet is going to need at least some IPv4 address space for the time being, so why screw it up for new entrants?..." Whether this is about reinventing final /8 or about people making money on IPv4 transfers does not make one jot of a difference. Remco (no hats) On Fri, May 8, 2015 at 1:54 PM Sebastian Wiesinger > wrote: * Dan L?dtke > [2015-05-08 11:33]: > See, we can not win this games. Let?s stop wasting energy and > resources on dealing with legacy IP and how to make it work for a > bit longer. New entrants are entering are market that is not fair, > and we can not make a real difference. The only way forward is to > push IPv6 and restore a healthy climate regarding the availability > of IP addresses. Dan, if you don't want to invest your time trying to make this market more fair by all means go ahead and do something else. There are still people here who would like to try so that new players can enter a market that will be dominated by IPv4 for some time to come. Most people here are pushing IPv6 but as much as you want to bury IPv4 it will still be around for some time. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant -------------- next part -------------- An HTML attachment was scrubbed... URL: From michele at blacknight.com Fri May 8 20:54:56 2015 From: michele at blacknight.com (Michele Neylon - Blacknight) Date: Fri, 8 May 2015 18:54:56 +0000 Subject: [address-policy-wg] New on RIPE Labs: IPv4 Transfers in the RIPE NCC Service Region In-Reply-To: <20150508115414.GA23553@danton.fire-world.de> References: <554A25E4.7060108@ripe.net> <895536294.20150507210413@infinitytelecom.ro> <20150508115414.GA23553@danton.fire-world.de> Message-ID: If there was a magical wand that we could wave to make every ISP switch on IPv6 the problems with IPv4 pricing etc., would vanish. Unfortunately it doesn?t exist. Pushing IPv6 adoption is commendable, but we have to be realistic. IPv4 won?t vanish anytime soon. -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains http://www.blacknight.host/ http://blog.blacknight.com/ http://www.blacknight.press - get our latest news & media coverage http://www.technology.ie Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Social: http://mneylon.social Random Stuff: http://www.michele.irish/ ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 On 08/05/2015 12:54, "Sebastian Wiesinger" wrote: >* Dan L?dtke [2015-05-08 11:33]: >> See, we can not win this games. Let?s stop wasting energy and >> resources on dealing with legacy IP and how to make it work for a >> bit longer. New entrants are entering are market that is not fair, >> and we can not make a real difference. The only way forward is to >> push IPv6 and restore a healthy climate regarding the availability >> of IP addresses. > >Dan, > >if you don't want to invest your time trying to make this market more >fair by all means go ahead and do something else. There are still >people here who would like to try so that new players can enter a >market that will be dominated by IPv4 for some time to come. > >Most people here are pushing IPv6 but as much as you want to bury IPv4 >it will still be around for some time. > >Regards > >Sebastian > >-- >GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) >'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. > -- Terry Pratchett, The Fifth Elephant From cfriacas at fccn.pt Sat May 9 00:38:32 2015 From: cfriacas at fccn.pt (Carlos Friacas) Date: Fri, 8 May 2015 23:38:32 +0100 (WEST) Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: <554B8590.8020702@seap.minhap.es> References: <5D23C81DA72B5A4CACB3B12075F7B347D7E4A9BD@SB00112A.adb.intra.admin.ch> <554B8590.8020702@seap.minhap.es> Message-ID: +1 support. Best Regards, Carlos Fria?as On Thu, 7 May 2015, Carlos G?mez Mu?oz wrote: > Dear all, > > We, seap.es, the LIR requesting IPv6 space for the government authorities in Spain, are facing the same problem as Switzerland. > > Therefore, I support the proposed policy change. > > Best regards, > > Carlos G?mez Mu?oz > Directorate for Information and Communication Technologies > Ministry of Finance and Public Administrations > > El 06/05/2015 a las 13:41, John.Collins at BIT.admin.ch escribi?: > > Hi all, > > ? > > speaking for the LIR requesting IPv6 space for the government authorities in Switzerland I support the proposed policy change.? Whereas the existing > policy wording promotes a non-wasteful use of addresses, it prevents the implementation of addressing plans that are aligned with federated > organisational structures where the principle of subsidiarity is followed and members are highly autonomous. Such addressing plans may be required in > large organisations or federations of autonomous states, which in addition to membership of the containing whole, may require autonomous routing and > addressing plans. > > ? > > kind regards, > > John Collins > > ? > > ch.swissgov > > FOITT > > An IT Service Provider of the Swiss Federal Administration > > ? > > > > From randy at psg.com Sat May 9 02:58:36 2015 From: randy at psg.com (Randy Bush) Date: Sat, 09 May 2015 09:58:36 +0900 Subject: [address-policy-wg] New on RIPE Labs: IPv4 Transfers in the RIPE NCC Service Region In-Reply-To: References: <554A25E4.7060108@ripe.net> <895536294.20150507210413@infinitytelecom.ro> <20150508115414.GA23553@danton.fire-world.de> Message-ID: > "...Personally I'm rather sick and tired of hearing people say 'yes, > let's break IPv4 so we all MUST move to IPv6'. If you think this is > good policy or even good engineering, please think again. It will make > us end up with a broken internet that, surprise, we won't be managing > any more. Breaking IPv4 might lead to increased IPv6 adoption, but not > on the internet as we know it today. Everybody who wants to connect > his organisation to the internet is going to need at least some IPv4 > address space for the time being, so why screw it up for new > entrants?..." > > Whether this is about reinventing final /8 or about people making > money on IPv4 transfers does not make one jot of a difference. bingo. we need to cut the religious zeal crap and remember we have paying customers who want us to move their packets. and many of those packets will be ipv4 for an embarrassingly long time. we may or may not like it, but it's reality; get over it. [ insert repeat of the reasons for the final /8 policy ] randy, sho works at an isp which deployed ipv6 commercially in 1997 From silvia.hagen at sunny.ch Mon May 11 08:37:07 2015 From: silvia.hagen at sunny.ch (Silvia Hagen) Date: Mon, 11 May 2015 06:37:07 +0000 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: References: Message-ID: Hi all I support this proposal +1 From my background as Chair of the Swiss IPv6 Council and many years of working with large organizations such as enterprises and governments, I know that basing an allocation size on number of users and size of network is not sufficient and does not allow them to create address plans that meet their various requirements. I think the RIPE NCC needs an open framework to be able to make meaningful allocations to such organizations, and thereby support and maybe even accelerate the deployment of IPv6 in the RIPE region. I therefore support it. Silvia Chair Swiss IPv6 Council -----Urspr?ngliche Nachricht----- Von: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] Im Auftrag von LIR (BIT I 5) Gesendet: Donnerstag, 7. Mai 2015 11:57 An: Address Policy Working Group Betreff: Re: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) Hello, I agree with this opinion. Therefore: +1 Carsten LIR de.government -----Urspr?ngliche Nachricht----- Von: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] Im Auftrag von James Blessing Gesendet: Dienstag, 28. April 2015 14:20 An: Address Policy Working Group Betreff: Re: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) On 28 April 2015 at 13:00, Marco Schmidt wrote: > > > The proposal aims to expand the criteria for evaluating initial IPv6 allocations larger than a /29. The RIPE NCC would consider additional aspects beyond only the number of existing users and extent of the organisation's infrastructure. > https://www.ripe.net/participate/policies/proposals/2015-03 Support at current stage - may change after seeing IA J -- James Blessing 07989 039 476 From ww at hubs.net.uk Mon May 11 10:19:51 2015 From: ww at hubs.net.uk (William Waites) Date: Mon, 11 May 2015 09:19:51 +0100 (BST) Subject: [address-policy-wg] mesh / community networks? 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: <555057B7.1010709@ripe.net> References: <555057B7.1010709@ripe.net> Message-ID: <20150511.091951.1451100927040230652.ww@hubs.net.uk> Hi Vesna! Nice to hear from you. You say that this is about governmental networks but that is not actually mentioned in the proposal itself. If you are correct then the proposal should be changed to explicitly mention that. If you are not correct then this just leaves more discretion to RIPE, which is fine -- I've always found the NCC to be rational and reasonable. For an organisation like HUBS which has small but autonomous member networks and a /29, we basically do: 2a04:5d00::/32 -- pool for /64 networks with /44 allocated to each member. 2a04:5d01::/32 -- pool for /48 networks with /40 allocated to each member (currently unused!). 2a04:5d02::/32 -- reserved. 2a04:5d03::/32 -- reserved. 2a04:5d04::/32 -- experimental 2a04:5d05::/32 -- reserved. 2a04:5d06::/32 -- reserved. 2a04:5d07::/32 -- reserved. In a country with 5 million population -- even several times that -- this ought to be plenty. If we need more I would expect to have to justify it! This does not really bear on DFZ routing table size unless there is a global policy on the horizon that will forbid announcing /44 or /40 networks i.e. when one of our members becomes multi-homed. The current policy says, "If so, the allocation size will be based on the number of existing users and the extent of the organisation's infrastructure." Deleting this is ok. Also ok would be substituting "extent and structure" for "extent". Without knowing any better I would have interpreted this as giving equal weight to number of users and topology. If you have a lot of users you get a big allocation. If your topology justifies you get a big allocation. So it may actually be that we don't even need a new policy, just more clarity on the interpretation. Cheers, -w On Mon, 11 May 2015 09:18:15 +0200, Vesna Manojlovic said: > Hi, there is this policy proposal (below) that is going to > change criteria for allocations to _governmental_ / national > networks -- but!! Maybe it can be used for the community > networks too?? > Would you be interested in reading this proposal, and seeing if > it would be sufficient, or are there any modifications possible > to suit your needs? > Now is the time :) > If you have any questions about "policy development process", > please let me know! > In short: you (anyone) can write to the mailing list below, and > say what you think of this proposal - agree, disagree, or how it > could be modified, and why. Then there will be more discussion, > proposal might get changed and finally accepted -- or > refused. If it's accepted, it becomes a new "policy", that is: > rules for allocating IPv6 to LIrs -- or their customers! > Concretely, if "additional aspects" can be expressed in terms > that "participants in mesh network are not countable customers" > and there is no "infrastructure" in the mesh... then maybe this > will work out better for the future community networks. > Thanks, Vesna > -------- Forwarded Message -------- Subject: [staff] > [policy-announce] 2015-03 New Policy Proposal (Assessment > Criteria for IPv6 Initial Allocation Size) Date: Tue, 28 Apr > 2015 14:00:40 +0200 From: Marco Schmidt > Reply-To: address-policy-wg at ripe.net To: > policy-announce at ripe.net CC: address-policy-wg at ripe.net > Dear colleagues, > A proposed change to the RIPE Document "IPv6 Address Allocation > and Assignment Policy" now is open for discussion. > The proposal aims to expand the criteria for evaluating initial > IPv6 allocations larger than a /29. The RIPE NCC would consider > additional aspects beyond only the number of existing users and > extent of the organisation's infrastructure. > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2015-03 > We encourage you to review this proposal and send your comments > to before 27 May 2015. > Regards > Marco Schmidt Policy Development Officer RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From frettled at gmail.com Mon May 11 10:28:11 2015 From: frettled at gmail.com (Jan Ingvoldstad) Date: Mon, 11 May 2015 10:28:11 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <914553914.20150428031241@infinitytelecom.ro> References: <93adac05882046f09e903dde75bc021f@EX13-MBX-13.ad.syr.edu> <02ce01d07de3$3b557990$b2006cb0$@a2b-internet.com> <465190781.20150425131345@infinitytelecom.ro> <3121571429968135@web8m.yandex.ru> <20150425132825.GH54385@Space.Net> <1605979109.20150425165206@infinitytelecom.ro> <20150425210717.GJ54385@Space.Net> <329311430068171@web6j.yandex.ru> <20150426191201.GQ54385@Space.Net> <553DF386.9000506@v4escrow.net> <1002571430125916@web2h.yandex.ru> <914553914.20150428031241@infinitytelecom.ro> Message-ID: On Tue, Apr 28, 2015 at 2:12 AM, Infinity Telecom SRL wrote: > Hello, > > > This is the question: "Could any of you have your company survive with > only a /22 (and 10-15 $/IP extra, 256/512/1024 packs towards 15$/IP) ? " > Ok, I'll bite, as you seem to have a hangup about this. This depends a lot on what the business is. My employer is situated in one of the top 5 most expensive countries in the world (Norway, you may have heard about it), so in order to be competitive, we have to keep the gap between revenue and expenses minimal. Any price increase from our partners/vendors affects that negatively, and in some regards, 2015 started badly for us with a weakened currency towards the Euro, USD, and most other currencies. You probably think you know where this is leading, that I would post a statement agreeing with you, that the answer to your question is a resounding "no". If so, you're wrong. The answer is a very clear "yes". Additionally, you have a hangup about "survival". For most of us who are already doing business, I believe the problem is not about SURVIVAL. If it is, there is something very wrong with your business model. The problem is about GROWTH potential, though, and that potential is best with IPv6, not IPv4. IPv4's growth potential is a dead end, and that's been well-known for several years. Get over it. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From frettled at gmail.com Mon May 11 10:31:58 2015 From: frettled at gmail.com (Jan Ingvoldstad) Date: Mon, 11 May 2015 10:31:58 +0200 Subject: [address-policy-wg] 2015-02 New Policy Proposal (Keep IPv6 PI When Requesting IPv6 Allocation) In-Reply-To: References: Message-ID: On Tue, Apr 14, 2015 at 2:52 PM, Marco Schmidt wrote: > > Dear colleagues, > > A proposed change to RIPE Document "IPv6 Address Allocation and Assignment > Policy" > is now available for discussion. > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2015-02 This proposal is eminently sensible, and I support it. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From frettled at gmail.com Mon May 11 10:37:34 2015 From: frettled at gmail.com (Jan Ingvoldstad) Date: Mon, 11 May 2015 10:37:34 +0200 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: References: Message-ID: On Tue, Apr 28, 2015 at 2:00 PM, Marco Schmidt wrote: > > Dear colleagues, > > A proposed change to the RIPE Document "IPv6 Address Allocation and > Assignment Policy" now is open for discussion. > > The proposal aims to expand the criteria for evaluating initial IPv6 > allocations larger than a /29. The RIPE NCC would consider additional > aspects beyond only the number of existing users and extent of the > organisation's infrastructure. > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2015-03 I think this change makes sense. Although I'd personally like to see stricter requirements and smaller allocations sizes for IPv6 in general, the proposed change does not make things worse from my point of view. So I support it. :) -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Mon May 11 11:10:36 2015 From: gert at space.net (Gert Doering) Date: Mon, 11 May 2015 11:10:36 +0200 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: References: Message-ID: <20150511091036.GB54385@Space.Net> Hi, On Mon, May 11, 2015 at 10:37:34AM +0200, Jan Ingvoldstad wrote: > Although I'd personally like to see stricter requirements and smaller > allocations sizes for IPv6 in general, Slightly off-track, but you made me curious. Given the number of /29s and /32s available in FP001, and the potential numbers of LIRs in the future (like, things explode and we'll see 100.000 LIRs) - where do you see the problem with our allocation sizes? I think we should balance between "too big" (aka: FP001 fills up, and new LIRs won't be able to get what they need [or we start using FP010]) and "too small" (aka: LIRs will have to squeeze inside, and resort to unwanted behaviour, like "give customers only a single /64" or even "single /128"). I see "/32 as default, up to /29 if you ask" as very reasonable middle ground... Gert Doering -- speaking as IPv6 user who does math -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From Mathew.Newton643 at official.mod.uk Mon May 11 12:46:29 2015 From: Mathew.Newton643 at official.mod.uk (Mathew Newton) Date: Mon, 11 May 2015 10:46:29 +0000 Subject: [address-policy-wg] mesh / community networks? 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: <20150511.091951.1451100927040230652.ww@hubs.net.uk> References: <555057B7.1010709@ripe.net> <20150511.091951.1451100927040230652.ww@hubs.net.uk> Message-ID: Hi William, > -----Original Message----- > From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of William Waites > Sent: 11 May 2015 09:20 > You say that this is about governmental networks but that is not > actually mentioned in the proposal itself. If you are correct then the > proposal should be changed to explicitly mention that. If you are not > correct then this just leaves more discretion to RIPE, which is fine > -- I've always found the NCC to be rational and reasonable. To clarify; the policy proposal is *not* aimed solely at governmental and/or multi-national networks. Whilst these may be the background and particular perspectives that drove the authors to submit the proposal it is very much intended to help satisfy the requirements of any organisation whose justified needs are not satisfied by what the authors consider to be bespoke and overly-specific assessment criteria in the current policy. This point of view is not intended to be an outright criticism of the policy as such, more a highlighting of the fact that much knowledge and experience has been gained since the criteria was first written (ripe-246 in 2002?) and that it is perhaps having unintended consequences given that valid requirements now exist that were not originally anticipated and/or catered for. On this point, the illustrative examples included in the proposal are non-exhaustive and definitely not intended to necessarily apply to all cases. Regards, Mathew From mschmidt at ripe.net Mon May 11 13:43:12 2015 From: mschmidt at ripe.net (Marco Schmidt) Date: Mon, 11 May 2015 13:43:12 +0200 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) Message-ID: Dear colleagues, The draft document for the proposal described in 2015-01, "Alignment of Transfer Requirements for IPv4 Allocations" has been published. The impact analysis that was conducted for this proposal has also been published. You can find the full proposal and the impact analysis at: https://www.ripe.net/participate/policies/proposals/2015-01 and the draft document at: https://www.ripe.net/participate/policies/proposals/2015-01/draft We encourage you to review this proposal and send your comments to address-policy-wg at ripe.net before 9 June 2015. Regards, Marco Schmidt Policy Development Officer RIPE NCC From frettled at gmail.com Mon May 11 14:04:44 2015 From: frettled at gmail.com (Jan Ingvoldstad) Date: Mon, 11 May 2015 14:04:44 +0200 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: References: Message-ID: On Mon, May 11, 2015 at 1:43 PM, Marco Schmidt wrote: > > You can find the full proposal and the impact analysis at: > > https://www.ripe.net/participate/policies/proposals/2015-01 > > and the draft document at: > > https://www.ripe.net/participate/policies/proposals/2015-01/draft > > We encourage you to review this proposal and send your comments to > address-policy-wg at ripe.net before 9 June 2015. The proposed change is sensible and clarifies what I have understood as the intent when the current policy was created. I could wish for more, but that is for another discussion and another change proposal. :) -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at inex.ie Mon May 11 15:08:11 2015 From: nick at inex.ie (Nick Hilliard) Date: Mon, 11 May 2015 15:08:11 +0200 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: <20150511091036.GB54385@Space.Net> References: <20150511091036.GB54385@Space.Net> Message-ID: <5550A9BB.3020403@inex.ie> On 11/05/2015 11:10, Gert Doering wrote: > I see "/32 as default, up to /29 if you ask" as very reasonable middle > ground... /29 gives 2^19 /48s, or a little over 500k /48s or 134 million /56s. Before supporting this proposal, I'd be interested to see a real life addressing plan which needed more than this amount of bit space. Nick From jim at rfc1035.com Mon May 11 15:13:53 2015 From: jim at rfc1035.com (Jim Reid) Date: Mon, 11 May 2015 14:13:53 +0100 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: <5550A9BB.3020403@inex.ie> References: <20150511091036.GB54385@Space.Net> <5550A9BB.3020403@inex.ie> Message-ID: <6A339043-FF62-4706-A10A-0DE13C059F35@rfc1035.com> On 11 May 2015, at 14:08, Nick Hilliard wrote: > Before supporting this proposal, I'd be interested to see a real life > addressing plan which needed more than this amount of bit space. +1 From callumstuart79 at gmail.com Mon May 11 15:02:01 2015 From: callumstuart79 at gmail.com (Callum Stuart) Date: Mon, 11 May 2015 21:02:01 +0800 Subject: [address-policy-wg] address-policy-wg Digest, Vol 45, Issue 8 In-Reply-To: References: Message-ID: <91DA37C68BCB47B6A78299EAE80C9D0E@gmail.com> Someone has made the comments on this article from ripe labs. Any comments from the community? How can this kind of thing happen in the ripe? Prior to the ripe depletion, it is even hard for my org to apply for a /19. Now my org can only apply for a /22! So as to keep low profile to have Lu Heng?s IPs sold. He had created another shell named Wuhan Yunwaiheng Information Technology Co., Ltd registered in Wuhan, Hubei Province of China ( its Chinese name is:?????????????). And then have his IPs sold under this new shell without attracting too much attentions from the RIPE community. He has earned more than 4millions USD for selling his IPs. By the way, cos of this business structure, he can avoid heaps of taxes which should be paid to Netherland Gov and Overseas Gov. Rijksuniversiteit Groningen ( this is where Lu heng graduated) 31.201.0.0/16 2011-04-28 PA SOLD AS35916 (US? 37.222.0.0/15 PA SOLD AS16276 ?ovh, France? ;AS35916 46.136.0.0/16 PA SOLD AS8312?kpn Netherland?;AS35916 5.132.0.0/16 2012-07-12 PA ( Split for sales? /17 left for future sale AS35916 5.224.0.0/15 2012-09-06 SOLD AS35916 178.236.224.0/20 PA Still available for Sale AS16276 Lu Heng still has /17 +/20 left available for Sale in RIPE and one aggregated Afrinic 154.80.0.0/12 ( Currently in Rental business). The Business structure of OutsideHeaven: The main Body of OutsideHeaven was registered in Tax heaven place ( Netherland). Then come the lower Body OutsideHeaven Hangzhou ( registered in Zhejiang Province of China) and the other lower Body Wuhan Yunwaiheng Information Technology ( registered in Hubei Province of China). Under this kind of structure, the company of Lu Heng has avoided to pay the taxes he should pay to the Chinese Government. His main Body registration info: His shell company?s registration info written in holland language. However, you can use google translate to understand. Please note this company does not pay any tax in Holland and in China. Online inzage uittreksel KvK-nummer 01133738 Deze inschrijving valt onder beheer van Kamer van Koophandel Noord-Nederland Onderneming Handelsnamen OutsideHeaven AnytimeChinese Voor Altijd Rechtsvorm Eenmanszaak Startdatum onderneming 26-06-2008 Activiteiten SBI-code: 620102 - Ontwikkelen en produceren van maatwerksoftware SBI-code: 6203 - Beheer van computerfaciliteiten Werkzame personen 0 Vestiging Vestigingsnummer 000005125421 Handelsnamen OutsideHeaven AnytimeChinese Voor Altijd Bezoekadres Esdoornlaan 656, 9741MH Groningen Telefoonnummer 0641734323 Internetadressen www.anytimechinese.com (http://www.anytimechinese.com) www.anytimechinese.net (http://www.anytimechinese.net) E-mailadres info at anytimechinese.com (mailto:info at anytimechinese.com) Datum vestiging 26-06-2008 Activiteiten SBI-code: 620102 - Ontwikkelen en produceren van maatwerksoftware SBI-code: 6203 - Beheer van computerfaciliteiten Webdesign. Het exploiteren van een informatieve website. Het geven van informatie over China aan ondernemers. De export van online gamecards. Het beheren van computernetwerken. ICT dienstverlening. Beheren van ICT infrastructuur. Werkzame personen 0 Eigenaar Naam Lu, Heng Geboortedatum en -plaats 01-09-1988, Onbekend, China Adres Esdoornlaan 656, 9741MH Groningen Datum in functie 26-06-2008 One of His Chinese Dummy Corporation named ????????????? in Chinese?English name: outside heaven If you look at its websites, there is no update since 2013 http://www.outsideheaven.com/zh-cn/news You can search the company registration info via link http://122.224.75.235:7082/wsdjpt/ The other of his Chinese Dummy Corporation named Wuhan Yunwaiheng Information Technology Co., Ltd registered in Wuhan, Hubei Province of China ( its Chinese name is:?????????????) You can search the company registration info via link http://gssoso.whhd.gov.cn/dhb/index.html Ironically, a Clever Chinese guy without ?Euro blood? can be "smart Enough" to have as many RIPE IPs as he can. On Saturday, May 9, 2015 at 2:55 AM, address-policy-wg-request at ripe.net (mailto:address-policy-wg-request at ripe.net) wrote: > Send address-policy-wg mailing list submissions to > address-policy-wg at ripe.net (mailto:address-policy-wg at ripe.net) > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ripe.net/mailman/listinfo/address-policy-wg > or, via email, send a message with subject or body 'help' to > address-policy-wg-request at ripe.net (mailto:address-policy-wg-request at ripe.net) > > You can reach the person managing the list at > address-policy-wg-owner at ripe.net (mailto:address-policy-wg-owner at ripe.net) > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of address-policy-wg digest..." > > > Today's Topics: > > 1. Re: New on RIPE Labs: IPv4 Transfers in the RIPE NCC Service > Region (Sebastian Wiesinger) > 2. Re: New on RIPE Labs: IPv4 Transfers in the RIPE NCC Service > Region (remco van mook) > 3. Re: New on RIPE Labs: IPv4 Transfers in the RIPE NCC Service > Region (Hannigan, Martin) > 4. Re: New on RIPE Labs: IPv4 Transfers in the RIPE NCC Service > Region (Michele Neylon - Blacknight) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 8 May 2015 13:54:14 +0200 > From: Sebastian Wiesinger > To: address-policy-wg at ripe.net (mailto:address-policy-wg at ripe.net) > Subject: Re: [address-policy-wg] New on RIPE Labs: IPv4 Transfers in > the RIPE NCC Service Region > Message-ID: <20150508115414.GA23553 at danton.fire-world.de (mailto:20150508115414.GA23553 at danton.fire-world.de)> > Content-Type: text/plain; charset="utf-8" > > * Dan L?dtke [2015-05-08 11:33]: > > See, we can not win this games. Let?s stop wasting energy and > > resources on dealing with legacy IP and how to make it work for a > > bit longer. New entrants are entering are market that is not fair, > > and we can not make a real difference. The only way forward is to > > push IPv6 and restore a healthy climate regarding the availability > > of IP addresses. > > > > > Dan, > > if you don't want to invest your time trying to make this market more > fair by all means go ahead and do something else. There are still > people here who would like to try so that new players can enter a > market that will be dominated by IPv4 for some time to come. > > Most people here are pushing IPv6 but as much as you want to bury IPv4 > it will still be around for some time. > > Regards > > Sebastian > > -- > GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) > 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. > -- Terry Pratchett, The Fifth Elephant > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 616 bytes > Desc: Digital signature > URL: > > ------------------------------ > > Message: 2 > Date: Fri, 08 May 2015 13:40:44 +0000 > From: remco van mook > To: address-policy-wg at ripe.net (mailto:address-policy-wg at ripe.net) > Subject: Re: [address-policy-wg] New on RIPE Labs: IPv4 Transfers in > the RIPE NCC Service Region > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > Three years and one day ago, I wrote on this very list: > > "...Personally I'm rather sick and tired of hearing people say 'yes, > let's break > IPv4 so we all MUST move to IPv6'. If you think this is good policy or even > good engineering, please think again. It will make us end up with a broken > internet that, surprise, we won't be managing any more. Breaking IPv4 might > lead to increased IPv6 adoption, but not on the internet as we know it > today. Everybody who wants to connect his organisation to the internet is > going to need at least some IPv4 address space for the time being, so why > screw it up for new entrants?..." > > Whether this is about reinventing final /8 or about people making money on > IPv4 transfers does not make one jot of a difference. > > > Remco > > (no hats) > > > > On Fri, May 8, 2015 at 1:54 PM Sebastian Wiesinger > wrote: > > > * Dan L?dtke [2015-05-08 11:33]: > > > See, we can not win this games. Let?s stop wasting energy and > > > resources on dealing with legacy IP and how to make it work for a > > > bit longer. New entrants are entering are market that is not fair, > > > and we can not make a real difference. The only way forward is to > > > push IPv6 and restore a healthy climate regarding the availability > > > of IP addresses. > > > > > > > > > Dan, > > > > if you don't want to invest your time trying to make this market more > > fair by all means go ahead and do something else. There are still > > people here who would like to try so that new players can enter a > > market that will be dominated by IPv4 for some time to come. > > > > Most people here are pushing IPv6 but as much as you want to bury IPv4 > > it will still be around for some time. > > > > Regards > > > > Sebastian > > > > -- > > GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) > > 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE > > SCYTHE. > > -- Terry Pratchett, The Fifth Elephant > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 3 > Date: Fri, 8 May 2015 16:59:03 +0000 > From: "Hannigan, Martin" > To: remco van mook , > "address-policy-wg at ripe.net (mailto:address-policy-wg at ripe.net)" > Subject: Re: [address-policy-wg] New on RIPE Labs: IPv4 Transfers in > the RIPE NCC Service Region > Message-ID: <3BDA1D6C-D32C-44B7-971F-A0A3DDE89DB0 at akamai.com (mailto:3BDA1D6C-D32C-44B7-971F-A0A3DDE89DB0 at akamai.com)> > Content-Type: text/plain; charset="utf-8" > > > > +1 > > Best, > > -M< > > > > > On May 8, 2015, at 9:40 AM, remco van mook > wrote: > > Three years and one day ago, I wrote on this very list: > > > "...Personally I'm rather sick and tired of hearing people say 'yes, let's break IPv4 so we all MUST move to IPv6'. If you think this is good policy or even good engineering, please think again. It will make us end up with a broken internet that, surprise, we won't be managing any more. Breaking IPv4 might lead to increased IPv6 adoption, but not on the internet as we know it today. Everybody who wants to connect his organisation to the internet is going to need at least some IPv4 address space for the time being, so why screw it up for new entrants?..." > > Whether this is about reinventing final /8 or about people making money on IPv4 transfers does not make one jot of a difference. > > > Remco > > (no hats) > > > On Fri, May 8, 2015 at 1:54 PM Sebastian Wiesinger > wrote: > * Dan L?dtke > [2015-05-08 11:33]: > > See, we can not win this games. Let?s stop wasting energy and > > resources on dealing with legacy IP and how to make it work for a > > bit longer. New entrants are entering are market that is not fair, > > and we can not make a real difference. The only way forward is to > > push IPv6 and restore a healthy climate regarding the availability > > of IP addresses. > > > > > Dan, > > if you don't want to invest your time trying to make this market more > fair by all means go ahead and do something else. There are still > people here who would like to try so that new players can enter a > market that will be dominated by IPv4 for some time to come. > > Most people here are pushing IPv6 but as much as you want to bury IPv4 > it will still be around for some time. > > Regards > > Sebastian > > -- > GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) > 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. > -- Terry Pratchett, The Fifth Elephant > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 4 > Date: Fri, 8 May 2015 18:54:56 +0000 > From: Michele Neylon - Blacknight > To: Sebastian Wiesinger , > "address-policy-wg at ripe.net (mailto:address-policy-wg at ripe.net)" > Subject: Re: [address-policy-wg] New on RIPE Labs: IPv4 Transfers in > the RIPE NCC Service Region > Message-ID: > Content-Type: text/plain; charset="utf-8" > > If there was a magical wand that we could wave to make every ISP switch on IPv6 the problems with IPv4 pricing etc., would vanish. > Unfortunately it doesn?t exist. > Pushing IPv6 adoption is commendable, but we have to be realistic. IPv4 won?t vanish anytime soon. > > > -- > Mr Michele Neylon > Blacknight Solutions > Hosting, Colocation & Domains > http://www.blacknight.host/ > http://blog.blacknight.com/ > http://www.blacknight.press - get our latest news & media coverage > http://www.technology.ie > Intl. +353 (0) 59 9183072 > Direct Dial: +353 (0)59 9183090 > Social: http://mneylon.social > Random Stuff: http://www.michele.irish/ > ------------------------------- > Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty > Road,Graiguecullen,Carlow,Ireland Company No.: 370845 > > > > > > > > > > On 08/05/2015 12:54, "Sebastian Wiesinger" wrote: > > > * Dan L?dtke [2015-05-08 11:33]: > > > See, we can not win this games. Let?s stop wasting energy and > > > resources on dealing with legacy IP and how to make it work for a > > > bit longer. New entrants are entering are market that is not fair, > > > and we can not make a real difference. The only way forward is to > > > push IPv6 and restore a healthy climate regarding the availability > > > of IP addresses. > > > > > > > > > Dan, > > > > if you don't want to invest your time trying to make this market more > > fair by all means go ahead and do something else. There are still > > people here who would like to try so that new players can enter a > > market that will be dominated by IPv4 for some time to come. > > > > Most people here are pushing IPv6 but as much as you want to bury IPv4 > > it will still be around for some time. > > > > Regards > > > > Sebastian > > > > -- > > GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) > > 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. > > -- Terry Pratchett, The Fifth Elephant > > > > > End of address-policy-wg Digest, Vol 45, Issue 8 > ************************************************ > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ak at list.ak.cx Mon May 11 15:30:42 2015 From: ak at list.ak.cx (Andre Keller) Date: Mon, 11 May 2015 15:30:42 +0200 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: References: Message-ID: <5550AF02.4080108@list.ak.cx> Hi, On 11.05.2015 13:43, Marco Schmidt wrote: > We encourage you to review this proposal and send your comments to > address-policy-wg at ripe.net before 9 June 2015. I support this proposal. I do not think that this will have a big impact, but it certainly brings the policy in alignment with the original intent. Regards Andr? From herve.clement at orange.com Mon May 11 15:32:35 2015 From: herve.clement at orange.com (herve.clement at orange.com) Date: Mon, 11 May 2015 13:32:35 +0000 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: <5550AF02.4080108@list.ak.cx> References: <5550AF02.4080108@list.ak.cx> Message-ID: <12236_1431351156_5550AF74_12236_1070_1_2AF4C0655C93DD4D9A005252D465A8082F625579@OPEXCLILM21.corporate.adroot.infra.ftgroup> +1 -----Message d'origine----- De?: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] De la part de Andre Keller Envoy??: lundi 11 mai 2015 15:31 ??: address-policy-wg at ripe.net Objet?: Re: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) Hi, On 11.05.2015 13:43, Marco Schmidt wrote: > We encourage you to review this proposal and send your comments to > address-policy-wg at ripe.net before 9 June 2015. I support this proposal. I do not think that this will have a big impact, but it certainly brings the policy in alignment with the original intent. Regards Andr? _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From frettled at gmail.com Mon May 11 15:58:46 2015 From: frettled at gmail.com (Jan Ingvoldstad) Date: Mon, 11 May 2015 15:58:46 +0200 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: <20150511091036.GB54385@Space.Net> References: <20150511091036.GB54385@Space.Net> Message-ID: On Mon, May 11, 2015 at 11:10 AM, Gert Doering wrote: > > > Slightly off-track, but you made me curious. Given the number of /29s and > /32s available in FP001, and the potential numbers of LIRs in the future > (like, things explode and we'll see 100.000 LIRs) - where do you see the > problem with our allocation sizes? > It's the old argument about quadrillions upon quadrillions (and more), and how it's setting up for possible future failure in a way that's going to be impossible to reverse at a later point in time. I do think it's too late to put the cat back in the bag, at least for large parts of how IPv6 addressing is handled, but I also don't think we need to compound failure with failure. I think we should balance between "too big" (aka: FP001 fills up, and > new LIRs won't be able to get what they need [or we start using FP010]) > and "too small" (aka: LIRs will have to squeeze inside, and resort to > unwanted behaviour, like "give customers only a single /64" or even > "single /128"). > I'm not sure that this is undesirable behaviour. If it's undesirable, it's because the entire system has been rigged to create the situation where it is undesirable, and then that is used as an excuse for what I consider excesses. > > I see "/32 as default, up to /29 if you ask" as very reasonable middle > ground... It is far more than reasonable, and even though someone can legitimately claim that they are making a setup where they can _use_ the entire IPv6 address space themselves by creating some convoluted network segmenting scheme, it doesn't mean it's reasonable to do so. Sure, having a /32 or greater permits us to easily use hexadecimal notation for 4-bit granularity network segmenting. I remain unconvinced, though, that this is necessary, even with an internet of things that's on the level of Karl Schroeder's Ventus. The change in policy text doesn't do anything about the practical limit, except leaving more up to the good minds at the NCC to consider this. Ideally, I'd think that there should be a hard limit at /29, and that there should be very good reasons ? reasons that need to be taken as a policy debate or something like that ? to go beyond that size. As Nick states, "I'd be interested to see a real life addressing plan which needed more than this amount of bit space." I'd actually be interested to see a real life addressing plan that needed a /32 bit address space, where the need isn't constructed based on the mere possibility of getting that space instead of merely e.g. a few hundre million times of the entire IPv4 space. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From richih.mailinglist at gmail.com Mon May 11 16:31:15 2015 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Mon, 11 May 2015 16:31:15 +0200 Subject: [address-policy-wg] [policy-announce] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: References: Message-ID: On Mon, May 11, 2015 at 1:43 PM, Marco Schmidt wrote: > The draft document for the proposal described in 2015-01, "Alignment of Transfer > Requirements for IPv4 Allocations" has been published. Strongest possible support; if anything, this does not go far enough. I will readily admit that I can not come up with a text which prevents abuse _and_ allows for valid operational needs, though. Richard From chrislist at de-punkt.de Mon May 11 16:26:29 2015 From: chrislist at de-punkt.de (Christopher Kunz) Date: Mon, 11 May 2015 16:26:29 +0200 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: References: Message-ID: <5550BC15.3040702@de-punkt.de> Am 11.05.15 um 13:43 schrieb Marco Schmidt: > Dear colleagues, > > > The draft document for the proposal described in 2015-01, "Alignment of Transfer > Requirements for IPv4 Allocations" has been published. > > The impact analysis that was conducted for this proposal has also been published. > > You can find the full proposal and the impact analysis at: > > https://www.ripe.net/participate/policies/proposals/2015-01 > > and the draft document at: > > https://www.ripe.net/participate/policies/proposals/2015-01/draft > > We encourage you to review this proposal and send your comments to > address-policy-wg at ripe.net before 9 June 2015. > > +1 from me. Best regards, --ck From swmike at swm.pp.se Mon May 11 16:36:45 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 11 May 2015 16:36:45 +0200 (CEST) Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: References: <20150511091036.GB54385@Space.Net> Message-ID: On Mon, 11 May 2015, Jan Ingvoldstad wrote: > As Nick states, "I'd be interested to see a real life addressing plan > which needed more than this amount of bit space." I'd actually be > interested to see a real life addressing plan that needed a /32 bit > address space, where the need isn't constructed based on the mere > possibility of getting that space instead of merely e.g. a few hundre > million times of the entire IPv4 space. -- Jan Since it's perfectly valid to ask for /48 per customer, with companies having tens of millions of customers, it's not a problem to motivate larger than /29. The proposed change doesn't change this at all as far as I can tell. -- Mikael Abrahamsson email: swmike at swm.pp.se From sebastian at karotte.org Mon May 11 16:44:49 2015 From: sebastian at karotte.org (Sebastian Wiesinger) Date: Mon, 11 May 2015 16:44:49 +0200 Subject: [address-policy-wg] [policy-announce] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: References: Message-ID: <20150511144449.GA24888@danton.fire-world.de> * Richard Hartmann [2015-05-11 16:33]: > On Mon, May 11, 2015 at 1:43 PM, Marco Schmidt wrote: > > > The draft document for the proposal described in 2015-01, "Alignment of Transfer > > Requirements for IPv4 Allocations" has been published. > > Strongest possible support; if anything, this does not go far enough. > > I will readily admit that I can not come up with a text which prevents > abuse _and_ allows for valid operational needs, though. I agree (both to the proposel and to the statement). I hope that perhaps we can come up with something useful at the APWG session this week. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 616 bytes Desc: Digital signature URL: From nick at inex.ie Mon May 11 16:47:06 2015 From: nick at inex.ie (Nick Hilliard) Date: Mon, 11 May 2015 16:47:06 +0200 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: References: <20150511091036.GB54385@Space.Net> Message-ID: <5550C0EA.3090506@inex.ie> On 11/05/2015 16:36, Mikael Abrahamsson wrote: > On Mon, 11 May 2015, Jan Ingvoldstad wrote: >> As Nick states, "I'd be interested to see a real life addressing plan >> which needed more than this amount of bit space." I'd actually be >> interested to see a real life addressing plan that needed a /32 bit >> address space, where the need isn't constructed based on the mere >> possibility of getting that space instead of merely e.g. a few hundre >> million times of the entire IPv4 space. -- Jan > > Since it's perfectly valid to ask for /48 per customer, with companies > having tens of millions of customers, it's not a problem to motivate larger > than /29. > > The proposed change doesn't change this at all as far as I can tell. this is already catered for in the existing policy, though. Nick From sander at steffann.nl Mon May 11 16:50:19 2015 From: sander at steffann.nl (Sander Steffann) Date: Mon, 11 May 2015 16:50:19 +0200 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: References: <20150511091036.GB54385@Space.Net> Message-ID: <69DAB968-4211-4856-9EF7-AFF57281777F@steffann.nl> Hi Jan, > I'd actually be interested to see a real life addressing plan that needed a /32 bit address space, where the need isn't constructed based on the mere possibility of getting that space instead of merely e.g. a few hundre million times of the entire IPv4 space. Giving significantly more than a single /64 to a single (home) user is part of the way IPv6 was designed. A /48 was a standard size from RFC 3177. It's successor RFC6177 is the current BCP. When working according to that BCP a /32 and even a /29 is really not that much. If you don't agree with an RFC/BCP then this is not the place to deal with that... Cheers, Sander From frettled at gmail.com Mon May 11 16:53:49 2015 From: frettled at gmail.com (Jan Ingvoldstad) Date: Mon, 11 May 2015 16:53:49 +0200 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: <69DAB968-4211-4856-9EF7-AFF57281777F@steffann.nl> References: <20150511091036.GB54385@Space.Net> <69DAB968-4211-4856-9EF7-AFF57281777F@steffann.nl> Message-ID: On Mon, May 11, 2015 at 4:50 PM, Sander Steffann wrote: > Hi Jan, > > > I'd actually be interested to see a real life addressing plan that > needed a /32 bit address space, where the need isn't constructed based on > the mere possibility of getting that space instead of merely e.g. a few > hundre million times of the entire IPv4 space. > > Giving significantly more than a single /64 to a single (home) user is > part of the way IPv6 was designed. A /48 was a standard size from RFC 3177. > It's successor RFC6177 is the current BCP. When working according to that > BCP a /32 and even a /29 is really not that much. > > If you don't agree with an RFC/BCP then this is not the place to deal with > that... > I'll be sure not to answer when asked the next time, thanks. :P -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.sleigh at ee.co.uk Mon May 11 16:53:44 2015 From: robert.sleigh at ee.co.uk (Sleigh, Robert) Date: Mon, 11 May 2015 14:53:44 +0000 Subject: [address-policy-wg] [policy-announce] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: <20150511144449.GA24888@danton.fire-world.de> References: <20150511144449.GA24888@danton.fire-world.de> Message-ID: <679694A32AB94046931C676BEF4BA8B8343249C3@UK31S005EXS06.EEAD.EEINT.CO.UK> +1 to this proposal Regards Bob Sleigh EE -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Sebastian Wiesinger Sent: 11 May 2015 15:45 To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] [policy-announce] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) * Richard Hartmann [2015-05-11 16:33]: > On Mon, May 11, 2015 at 1:43 PM, Marco Schmidt wrote: > > > The draft document for the proposal described in 2015-01, "Alignment > > of Transfer Requirements for IPv4 Allocations" has been published. > > Strongest possible support; if anything, this does not go far enough. > > I will readily admit that I can not come up with a text which prevents > abuse _and_ allows for valid operational needs, though. I agree (both to the proposel and to the statement). I hope that perhaps we can come up with something useful at the APWG session this week. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant NOTICE AND DISCLAIMER This e-mail (including any attachments) is intended for the above-named person(s). If you are not the intended recipient, notify the sender immediately, delete this email from your system and do not disclose or use for any purpose. We may monitor all incoming and outgoing emails in line with current legislation. We have taken steps to ensure that this email and attachments are free from any virus, but it remains your responsibility to ensure that viruses do not adversely affect you. EE Limited Registered in England and Wales Company Registered Number: 02382161 Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9BW. From sander at steffann.nl Mon May 11 17:10:51 2015 From: sander at steffann.nl (Sander Steffann) Date: Mon, 11 May 2015 17:10:51 +0200 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: References: <20150511091036.GB54385@Space.Net> <69DAB968-4211-4856-9EF7-AFF57281777F@steffann.nl> Message-ID: <8795AF37-B80A-47A3-BB98-E33F8CF08452@steffann.nl> Hi, > I'll be sure not to answer when asked the next time, thanks. :P Oh, please ask! :-) Be prepared to sometimes receive a redirect as an answer though ;) Cheers! Sander From david.freedman at uk.clara.net Mon May 11 17:15:57 2015 From: david.freedman at uk.clara.net (David Freedman) Date: Mon, 11 May 2015 15:15:57 +0000 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: References: Message-ID: Hi Marco, All, I'd just like Clarity on what could be some conflicting points in the impact analysis section of this document: It starts out with: "A. RIPE NCC's Understanding of the Proposed Policy -> The proposed policy would not affect existing procedures for mergers and acquisitions. The transfers of resources related to ownership changes of networks would remain possible at any time. The process of becoming a RIPE NCC member would not be impacted.: It then continues to say: "C. Impact of Policy on RIPE NCC Operations/Services -> Billing/Finance Department -> A RIPE NCC Executive Board resolution on 20 March 2015 requires that LIRs pay one full annual service fee before commencement of a merger, transfer or closure procedure. The proposed policy change would require LIRs to keep their IPv4 allocation for at least 24 months before it could be transferred and pay the annual fee during this time" So, in the case of a merger related to ownership (I.e Company A acquires Company B) and Company B has one of these /22 allocations, then Company A has to wait for 24 months (and pay for two membership cycles) before being allowed to merge this in to their LIR? or did I misunderstand? Also, since I see no mention of this being retrospective in the proposal, I take it, that it will only apply to /22 allocations made from the date this proposal is accepted? and not before? Dave. From richih.mailinglist at gmail.com Mon May 11 17:25:59 2015 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Mon, 11 May 2015 17:25:59 +0200 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: References: Message-ID: On Mon, May 11, 2015 at 5:15 PM, David Freedman wrote: > Also, since I see no mention of this being retrospective in the proposal, > I take it, that it will only apply to /22 allocations made from the date > this proposal is accepted? and not before? My interpretation is exactly the other way around. Can we please get clarification? If your interpretation is correct, we can look forward to seeing ru.ibulavkin1024 soon. Richard From richih.mailinglist at gmail.com Mon May 11 17:48:59 2015 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Mon, 11 May 2015 17:48:59 +0200 Subject: [address-policy-wg] 2015-02 New Policy Proposal (Keep IPv6 PI When Requesting IPv6 Allocation) In-Reply-To: References: Message-ID: Belated +1 Richard Sent by mobile; excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mschmidt at ripe.net Mon May 11 18:06:09 2015 From: mschmidt at ripe.net (Marco Schmidt) Date: Mon, 11 May 2015 18:06:09 +0200 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: References: Message-ID: <5550D371.4080505@ripe.net> Hi David, Thanks for your question - it's good to be able to provide clarity. The proposal would apply to allocations that were made in the past. When the RIPE NCC received a transfer request, we would check to see that at least 24 months had elapsed since the allocation was made. For example, a /22 allocation that was made 23 months before the proposal was accepted would have a waiting period of one month before it could be transferred. Regarding your other question, the proposal being discussed doesn't apply to mergers or acquisitions. The Executive Board resolution mentioned in the impact analysis is separate to the proposal and *does* affect transfers, mergers, acquisitions and closures, and simply requires that the full 12 month membership fee must be paid before a new LIR can do any of these things. So, in your example, Company B would be able to merge with Company A immediately. However, if it was only two months old, it would need to pay a full 12 month membership fee before this could be processed. As Company A and B are merging, this is not considered a transfer, so the 24 month restriction would not apply. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC On 11/05/15 17:15, David Freedman wrote: > Hi Marco, All, > > I'd just like Clarity on what could be some conflicting points in the > impact analysis section of this document: > > It starts out with: > > "A. RIPE NCC's Understanding of the Proposed Policy -> The proposed policy > would not affect existing procedures for mergers and acquisitions. The > transfers of resources related to ownership changes of networks would > remain possible at any time. The process of becoming a RIPE NCC member > would not be impacted.: > > It then continues to say: > > "C. Impact of Policy on RIPE NCC Operations/Services -> Billing/Finance > Department -> A RIPE NCC Executive Board resolution on 20 March 2015 > requires that LIRs pay one full annual service fee before commencement of > a merger, transfer or closure procedure. The proposed policy change would > require LIRs to keep their IPv4 allocation for at least 24 months before > it could be transferred and pay the annual fee during this time" > > So, in the case of a merger related to ownership (I.e Company A acquires > Company B) and Company B has one of these /22 allocations, then Company A > has to wait for 24 months (and pay for two membership cycles) before being > allowed to merge this in to their LIR? or did I misunderstand? > > Also, since I see no mention of this being retrospective in the proposal, > I take it, that it will only apply to /22 allocations made from the date > this proposal is accepted? and not before? > > Dave. > > > From ripe-wgs at radu-adrian.feurdean.net Mon May 11 18:42:23 2015 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Mon, 11 May 2015 18:42:23 +0200 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: <5550D371.4080505@ripe.net> References: <5550D371.4080505@ripe.net> Message-ID: <1431362543.1661071.265793865.35424261@webmail.messagingengine.com> On Mon, May 11, 2015, at 18:06, Marco Schmidt wrote: > The proposal would apply to allocations that were made in the past. When > the RIPE NCC received a transfer request, we would check to see that at > least 24 months had elapsed since the allocation was made. For example, > a /22 allocation that was made 23 months before the proposal was > accepted would have a waiting period of one month before it could be > transferred. > > Regarding your other question, the proposal being discussed doesn't > apply to mergers or acquisitions. The Executive Board resolution > mentioned in the impact analysis is separate to the proposal and *does* > affect transfers, mergers, acquisitions and closures, and simply > requires that the full 12 month membership fee must be paid before a new > LIR can do any of these things. This way it's fine for mee too. +1 From apwg at c4inet.net Mon May 11 19:00:08 2015 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Mon, 11 May 2015 18:00:08 +0100 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: <5550D371.4080505@ripe.net> References: <5550D371.4080505@ripe.net> Message-ID: <20150511170007.GH35191@cilantro.c4inet.net> On Mon, May 11, 2015 at 06:06:09PM +0200, Marco Schmidt wrote: >The proposal would apply to allocations that were made in the past. >When the RIPE NCC received a transfer request, we would check to see >that at least 24 months had elapsed since the allocation was made. For >example, a /22 allocation that was made 23 months before the proposal >was accepted would have a waiting period of one month before it could >be transferred. I do not think the NCC should go down the road of applying policy changes ex post facto. A LIR can reasonably expect that conditions attached at the time of allocation/assignment of a resource would continue to obtain throughout the lifetime of that assignment. Why, a policy could be enacted that retroactively invalidates allocation/assignment criteria, resulting in LIRs having to return most or all of their allocations. Or, how a bout a retroactive charging scheme? In light of this, I will oppose this proposal. For what that will turn out to be worth. rgds, Sascha Luck From d.baeza at tvt-datos.es Mon May 11 19:15:58 2015 From: d.baeza at tvt-datos.es (Daniel Baeza (Red y Sistemas TVT)) Date: Mon, 11 May 2015 19:15:58 +0200 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: <5550D371.4080505@ripe.net> References: <5550D371.4080505@ripe.net> Message-ID: <5550E3CE.8040103@tvt-datos.es> Hi Marco, It will be retroactive? How this will be handled? How RIPE will ask to the LIRs that have been closed to reopen it and recieve back the allocation taking it away from the actual owner, who payed it? In the proposal I didnt saw anything mentioning the retroactive of the policy and how it will be handled. Regards, El 11/05/2015 a las 18:06, Marco Schmidt escribi?: > Hi David, > > Thanks for your question - it's good to be able to provide clarity. > > The proposal would apply to allocations that were made in the past. When > the RIPE NCC received a transfer request, we would check to see that at > least 24 months had elapsed since the allocation was made. For example, > a /22 allocation that was made 23 months before the proposal was > accepted would have a waiting period of one month before it could be > transferred. > > Regarding your other question, the proposal being discussed doesn't > apply to mergers or acquisitions. The Executive Board resolution > mentioned in the impact analysis is separate to the proposal and *does* > affect transfers, mergers, acquisitions and closures, and simply > requires that the full 12 month membership fee must be paid before a new > LIR can do any of these things. > > So, in your example, Company B would be able to merge with Company A > immediately. However, if it was only two months old, it would need to > pay a full 12 month membership fee before this could be processed. As > Company A and B are merging, this is not considered a transfer, so the > 24 month restriction would not apply. > > Kind regards, > Marco Schmidt > Policy Development Officer > RIPE NCC > > On 11/05/15 17:15, David Freedman wrote: >> Hi Marco, All, >> >> I'd just like Clarity on what could be some conflicting points in the >> impact analysis section of this document: >> >> It starts out with: >> >> "A. RIPE NCC's Understanding of the Proposed Policy -> The proposed policy >> would not affect existing procedures for mergers and acquisitions. The >> transfers of resources related to ownership changes of networks would >> remain possible at any time. The process of becoming a RIPE NCC member >> would not be impacted.: >> >> It then continues to say: >> >> "C. Impact of Policy on RIPE NCC Operations/Services -> Billing/Finance >> Department -> A RIPE NCC Executive Board resolution on 20 March 2015 >> requires that LIRs pay one full annual service fee before commencement of >> a merger, transfer or closure procedure. The proposed policy change would >> require LIRs to keep their IPv4 allocation for at least 24 months before >> it could be transferred and pay the annual fee during this time" >> >> So, in the case of a merger related to ownership (I.e Company A acquires >> Company B) and Company B has one of these /22 allocations, then Company A >> has to wait for 24 months (and pay for two membership cycles) before being >> allowed to merge this in to their LIR? or did I misunderstand? >> >> Also, since I see no mention of this being retrospective in the proposal, >> I take it, that it will only apply to /22 allocations made from the date >> this proposal is accepted? and not before? >> >> Dave. >> >> >> > > -- Daniel Baeza Centro de Observaci?n de Red Dpto. Red y Sistemas Television Costa Blanca S.L. Telf. 966.190.847 | Fax. 965.074.390 http://www.tvt.es | http://www.tvt-datos.es Correo: d.baeza at tvt-datos.es -- [Atenci?n] La informaci?n contenida en este e-mail es confidencial, privilegiada y est? dirigida exclusivamente a su destinatario. Cualquier revisi?n, difusi?n, distribuci?n o copiado de este mensaje sin autorizaci?n del propietario est? prohibido. Si ha recibido este e-mail por error por favor b?rrelo y env?e un mensaje al remitente. [Disclaimer] The information contained in this e-mail is privileged and confidential and is intended only for its addressee. Any review, dissemination, distribution or copying of this e-mail is prohibited. If you have received it in error please delete the original message and e-mail us. (!) El medio ambiente es responsabilidad de todos. Imprime este mail si es absolutamente necesario. From apwg at c4inet.net Mon May 11 19:19:39 2015 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Mon, 11 May 2015 18:19:39 +0100 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: References: <20150511091036.GB54385@Space.Net> Message-ID: <20150511171938.GI35191@cilantro.c4inet.net> On Mon, May 11, 2015 at 03:58:46PM +0200, Jan Ingvoldstad wrote: >As Nick states, "I'd be interested to see a real life addressing plan which >needed more than this amount of bit space." I'd actually be interested to >see a real life addressing plan that needed a /32 bit address space, where >the need isn't constructed based on the mere possibility of getting that >space instead of merely e.g. a few hundre million times of the entire IPv4 >space. The way I read the proposal, it is not about assignment sizes but about a "aggregation" vs "conservation" conflict. The proponents have, AIUI, a problem where they might not fully assign a /32 or /29 allocation but have different routing policies for parts of their network, which cannot be satisfied without violating s3.4 of ripe-641. rgds, Sascha Luck From ripe-wgs at radu-adrian.feurdean.net Mon May 11 19:24:46 2015 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Mon, 11 May 2015 19:24:46 +0200 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: <20150511170007.GH35191@cilantro.c4inet.net> References: <5550D371.4080505@ripe.net> <20150511170007.GH35191@cilantro.c4inet.net> Message-ID: <1431365086.1672205.265832225.2D1A5F90@webmail.messagingengine.com> On Mon, May 11, 2015, at 19:00, Sascha Luck [ml] wrote: > Why, a policy could be enacted that retroactively invalidates > allocation/assignment criteria, resulting in LIRs having to It is not retroactive, and it does not change the allocation criteria. It only changes transfer rules, and my understanding is that it will only apply from the moment it becomes policy (at best, more realistic is the time NCC is ready to implement, which may be some days/weeks later). What you say is suggesting the fact that obtaining an allocation for the sole purpose of transfer is acceptable behaviour, and I suppose most people here don't agree with that. From ak at list.ak.cx Mon May 11 19:25:42 2015 From: ak at list.ak.cx (Andre Keller) Date: Mon, 11 May 2015 19:25:42 +0200 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: <5550E3CE.8040103@tvt-datos.es> References: <5550D371.4080505@ripe.net> <5550E3CE.8040103@tvt-datos.es> Message-ID: <5550E616.60503@list.ak.cx> Hi, On 11.05.2015 19:15, Daniel Baeza (Red y Sistemas TVT) wrote: > It will be retroactive? How this will be handled? If my interpretation of the IA is correct, the retroactive part is restricted to evaluation of transfer requests. It means if/once the policy is implemented, it applies to resources already allocated by RIPE NCC but not yet transferred. Resources already transferred wont be affected. I think this is a sensible approach. Regards Andr? From d.baeza at tvt-datos.es Mon May 11 19:29:23 2015 From: d.baeza at tvt-datos.es (Daniel Baeza (Red y Sistemas TVT)) Date: Mon, 11 May 2015 19:29:23 +0200 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: <5550E616.60503@list.ak.cx> References: <5550D371.4080505@ripe.net> <5550E3CE.8040103@tvt-datos.es> <5550E616.60503@list.ak.cx> Message-ID: <5550E6F3.70702@tvt-datos.es> Hi El 11/05/2015 a las 19:25, Andre Keller escribi?: > Hi, > > On 11.05.2015 19:15, Daniel Baeza (Red y Sistemas TVT) wrote: >> It will be retroactive? How this will be handled? > > If my interpretation of the IA is correct, the retroactive part is > restricted to evaluation of transfer requests. It means if/once the > policy is implemented, it applies to resources already allocated by RIPE > NCC but not yet transferred. Resources already transferred wont be > affected. I think this is a sensible approach. Quoting Marco: >The proposal would apply to allocations that were made in the past. >Whenthe RIPE NCC received a transfer request, we would check to see >that at least 24 months had elapsed since the allocation was made. For >example, a /22 allocation that was made 23 months before the proposal >was accepted would have a waiting period of one month before it could >be transferred. What kind of allocations is talking Marco about? RIPE to LIR or LIR to LIR? Regards, From apwg at c4inet.net Mon May 11 19:32:44 2015 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Mon, 11 May 2015 18:32:44 +0100 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: <1431365086.1672205.265832225.2D1A5F90@webmail.messagingengine.com> References: <5550D371.4080505@ripe.net> <20150511170007.GH35191@cilantro.c4inet.net> <1431365086.1672205.265832225.2D1A5F90@webmail.messagingengine.com> Message-ID: <20150511173244.GJ35191@cilantro.c4inet.net> On Mon, May 11, 2015 at 07:24:46PM +0200, Radu-Adrian FEURDEAN wrote: >On Mon, May 11, 2015, at 19:00, Sascha Luck [ml] wrote: >> Why, a policy could be enacted that retroactively invalidates >> allocation/assignment criteria, resulting in LIRs having to > >It is not retroactive, and it does not change the allocation criteria. >It only changes transfer rules, and my understanding is that it will >only apply from the moment it becomes policy (at best, more realistic is >the time NCC is ready to implement, which may be some days/weeks later). The IA states that it will be retroactively applied to resources already allocated but not (yet?) transferred. It changes the allocation criteria insofar as it is, until now, implied that an allocation can be transferred immediately - even if that isn't explicitly stated. >What you say is suggesting the fact that obtaining an allocation for the >sole purpose of transfer is acceptable behaviour, and I suppose most >people here don't agree with that. Until the proposal passes and is implemented, it *is* acceptable (or at least legal) behaviour. rgds, Sascha Luck From apwg at c4inet.net Mon May 11 19:45:31 2015 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Mon, 11 May 2015 18:45:31 +0100 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: <5550E616.60503@list.ak.cx> References: <5550D371.4080505@ripe.net> <5550E3CE.8040103@tvt-datos.es> <5550E616.60503@list.ak.cx> Message-ID: <20150511174531.GK35191@cilantro.c4inet.net> On Mon, May 11, 2015 at 07:25:42PM +0200, Andre Keller wrote: >If my interpretation of the IA is correct, the retroactive part is >restricted to evaluation of transfer requests. It means if/once the >policy is implemented, it applies to resources already allocated by RIPE >NCC but not yet transferred. Resources already transferred wont be >affected. I think this is a sensible approach. Your interpretation is the same as mine, correct or not ;) The crux is, though: it changes ripe-623, the "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" document, not a hypothetical "Transfer Policies" document. This sets a precedent for changing *everything else* in this document and applying the changes retrospectively. I can't be the only one who does not want to go there? rgds, Sascha Luck From elvis at v4escrow.net Mon May 11 19:47:55 2015 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Mon, 11 May 2015 19:47:55 +0200 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: <20150511170007.GH35191@cilantro.c4inet.net> References: <5550D371.4080505@ripe.net> <20150511170007.GH35191@cilantro.c4inet.net> Message-ID: <5550EB4B.5000408@v4escrow.net> Hi Sacha, On 11/05/15 19:00, Sascha Luck [ml] wrote: > In light of this, I will oppose this proposal. For what that will > turn out to be worth. if I understand correctly, you are opposing to the RIPE NCC's planned implementation of this proposal (under the terms and understanding of this Impact Analysis), is that correct? What If once the policy proposal would become policy and would be implemented, _all all allocations made after the implementation date_ will need to have a 2 years 'buffer' - would that be acceptable? I just want to clearly understand the reason for opposing. regards, Elvis -- Elvis Daniel Velea Chief Executive Officer Email: elvis at V4Escrow.net US Phone: +1 (702) 475 5914 EU Phone: +31 (0) 61458 1914 Recognised IPv4 Broker/Facilitator in: This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received this email in error, please notify the sender immediately and delete the original.Any other use of this email is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 5043 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1.png Type: image/png Size: 11971 bytes Desc: not available URL: From apwg at c4inet.net Mon May 11 19:52:02 2015 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Mon, 11 May 2015 18:52:02 +0100 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: <5550EB4B.5000408@v4escrow.net> References: <5550D371.4080505@ripe.net> <20150511170007.GH35191@cilantro.c4inet.net> <5550EB4B.5000408@v4escrow.net> Message-ID: <20150511175202.GL35191@cilantro.c4inet.net> On Mon, May 11, 2015 at 07:47:55PM +0200, Elvis Daniel Velea wrote: >On 11/05/15 19:00, Sascha Luck [ml] wrote: >if I understand correctly, you are opposing to the RIPE NCC's planned >implementation of this proposal (under the terms and understanding of >this Impact Analysis), is that correct? Yep, since I can't oppose the implementation plan separately, I have to consider it part of the proposal for PDP purposes. >What If once the policy proposal would become policy and would be >implemented, _all all allocations made after the implementation date_ >will need to have a 2 years 'buffer' - would that be acceptable? Yes, I'm not opposed to the "meat" of the proposal (now that it is clear that M&A are not affected), just to the retroactive implementation. rgds, Sascha Luck From richih.mailinglist at gmail.com Mon May 11 19:56:47 2015 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Mon, 11 May 2015 19:56:47 +0200 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: <5550EB4B.5000408@v4escrow.net> References: <5550D371.4080505@ripe.net> <20150511170007.GH35191@cilantro.c4inet.net> <5550EB4B.5000408@v4escrow.net> Message-ID: That potential two years grace period is an invitation to all IP grabbers to grab more. Richard Sent by mobile; excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis at v4escrow.net Mon May 11 20:14:24 2015 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Mon, 11 May 2015 20:14:24 +0200 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: <20150511174531.GK35191@cilantro.c4inet.net> References: <5550D371.4080505@ripe.net> <5550E3CE.8040103@tvt-datos.es> <5550E616.60503@list.ak.cx> <20150511174531.GK35191@cilantro.c4inet.net> Message-ID: <5550F180.6020702@v4escrow.net> Hi Sacha, On 11/05/15 19:45, Sascha Luck [ml] wrote: > On Mon, May 11, 2015 at 07:25:42PM +0200, Andre Keller wrote: >> If my interpretation of the IA is correct, the retroactive part is >> restricted to evaluation of transfer requests. It means if/once the >> policy is implemented, it applies to resources already allocated by RIPE >> NCC but not yet transferred. Resources already transferred wont be >> affected. I think this is a sensible approach. > > Your interpretation is the same as mine, correct or not ;) The > crux is, though: it changes ripe-623, the "IPv4 Address > Allocation and Assignment Policies for the RIPE NCC Service > Region" document, not a hypothetical "Transfer Policies" > document. correct... > This sets a precedent for changing *everything else* in > this document and applying the changes retrospectively. This has already happened before (remember 2007-01?) and it happens with every change of policy.. For example, criteria for making IPv4 assignments, 5 years ago, is no longer the same today, the IPv4 policy has changed several times since 2010 and everything that used to be policy in the past no longer matters, what matters is the latest policy document and not the criteria from years ago. > I can't be the only one who does not want to go there? I understand what you mean but, seriously, this will affect (based on the IA) a maximum of 580 /22s (and for a period of 1 day to 2 years depending on the date the allocation would be received vs policy implementation). It will not be a precedent, the precedent has been already approved years ago. I would not support an implementation that would require the RIPE NCC to apply the same policy differently for an allocation received on the 20th of July vs an allocation received on the 21st of July. This policy proposal's intent is to bring all allocations under the same umbrella (once implemented) and not create more umbrellas.. > > rgds, > Sascha Luck > regards, elvis -- Elvis Daniel Velea Chief Executive Officer Email: elvis at V4Escrow.net US Phone: +1 (702) 475 5914 EU Phone: +31 (0) 61458 1914 Recognised IPv4 Broker/Facilitator in: This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received this email in error, please notify the sender immediately and delete the original.Any other use of this email is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 5043 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1.png Type: image/png Size: 11971 bytes Desc: not available URL: From apwg at c4inet.net Mon May 11 20:59:30 2015 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Mon, 11 May 2015 19:59:30 +0100 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: <5550F180.6020702@v4escrow.net> References: <5550D371.4080505@ripe.net> <5550E3CE.8040103@tvt-datos.es> <5550E616.60503@list.ak.cx> <20150511174531.GK35191@cilantro.c4inet.net> <5550F180.6020702@v4escrow.net> Message-ID: <20150511185929.GM35191@cilantro.c4inet.net> On Mon, May 11, 2015 at 08:14:24PM +0200, Elvis Daniel Velea wrote: >This has already happened before (remember 2007-01?) and it happens >with every change of policy.. 2007-01 is a good example of why ex post facto changes are a bad idea. This was controversial then and is still controversial today, especially the application to resources long since assigned. Had I known then what I know now, I would have opposed it more stringently. >For example, criteria for making IPv4 assignments, 5 years ago, is no >longer the same today, the IPv4 policy has changed several times since >2010 and everything that used to be policy in the past no longer >matters, what matters is the latest policy document and not the >criteria from years ago. Well, had "last /8" been applied ex post facto, we would all have had to return our /20s and /16s etc. ;) (and we've seen ideas to that or similar effect floating around on the list these last few weeks!) As a LIR, I would want some security that what was perfectly appropriate last year does not suddenly expose me to sanction because someone decided, after the fact, that it should have been illegal all along. (not this proposal specifically, but the precedent) >It will not be a precedent, the precedent has been already approved >years ago. Thank you for proving my point. Because it was done for 2007-01 it can now be done for 2015-01. So if, next week, the community decides that all allocations > /22 should never have been made, I lose the ones I have already? Because it was already done for 2015-01 which was done because it was already done for 2007-01? >I would not support an implementation that would require the RIPE NCC >to apply the same policy differently for an allocation received on the >20th of July vs an allocation received on the 21st of July. This >policy proposal's intent is to bring all allocations under the same >umbrella (once implemented) and not create more umbrellas.. I'll only apply to allocations made >= 2 years before the implementation date for a maximum of 2 years. Not, IMO, such a problem. rgds, Sascha Luck From Mathew.Newton643 at official.mod.uk Mon May 11 21:27:17 2015 From: Mathew.Newton643 at official.mod.uk (Mathew Newton) Date: Mon, 11 May 2015 19:27:17 +0000 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: <5550A9BB.3020403@inex.ie> References: <20150511091036.GB54385@Space.Net> <5550A9BB.3020403@inex.ie> Message-ID: Hi Nick, > -----Original Message----- > From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Nick Hilliard > Sent: 11 May 2015 14:08 > > On 11/05/2015 11:10, Gert Doering wrote: > > I see "/32 as default, up to /29 if you ask" as very reasonable middle > > ground... > > /29 gives 2^19 /48s, or a little over 500k /48s or 134 million /56s. > > Before supporting this proposal, I'd be interested to see a real life > addressing plan which needed more than this amount of bit space. That is a perfectly reasonable question to ask (assuming it was effectively a question!). My difficulty however is adequately answering it without inadvertently releasing too much information about the UK MOD's infrastructure to a public mailing list. That is no one's problem but my own though so let me see how far I can get by at least covering some of the key principles. One clarification to get out of the way first given that this branch of the thread was a slight diversion from the core topic is that I am not looking at changing the '/32 as default, up to /29 if you ask' position as, like Gert, I agree that this is a very sensible default position. The issue presented is how to deal with those organisations who cannot fit within a /29, of which the UK MOD is one... As context for those not familiar, the UK MOD and Armed Forces are a large and complex organisation with an annual budget of over ?37 billion (?52 billion) which puts it in the world's 'top 5' militaries by such a measure. Its global IP infrastructure spans land, sea, air and space environments using practically all conceivable physical layer transport type. From an IPv6 addressing perspective, the best place to start is arguably with the end sites. There are 10's of thousands of end sites encompassing what you might regard as 'conventional' sites (office/corporate environments, datacentres, military bases, dockyards etc) as well as military platforms (tanks, aircraft, ships etc) some of which could be regarded as enterprises in their own right (e.g. aircraft carriers). These end sites achieve their wider connectivity via ISPs (generally, but not exclusively, 'private' ISPs whose services are exclusive to the UK MOD) of which there are hundreds in each different geographic operating area (fixed UK, fixed overseas, deployed etc). Most end sites would connect to multiple ISPs, either simultaneously or varying over time (long term infrastructure changes down to short term connectivity changes in support of operations) and there is expected to be a mix of how to deal with this from an addressing perspective (readdressing, multiple prefixes, mobile IP, etc). In order to achieve aggregation and efficiency of routing (within the MOD, to other nations' militaries and to the Internet) this 'geographic area > ISP > end site' hierarchy becomes a key part of the addressing strategy. It is not a flat network and cannot be treated as one by the addressing strategy hence a straightforward 'number of end sites' calculation does not result in sufficient address space to be allocated. The issue is further compounded by the fact that the UK MOD must abide by national security policy which requires that ALL information that is generated, collected, stored, processed or shared is afforded the appropriate degree of protection according to its sensitivity and level of threat it faces. Security classifications are used to categorise the different levels of sensitivity/threat and effective delivery of these lead to the requirement to operate completely independent infrastructures with discrete routing policies for each classification hence multiple allocations are effectively required. The option of 'luxuries' such as semantics, nibble boundaries, 'just in case' expansion bits etc do not feature in the UK MOD's IPv6 addressing strategy - it is very much a 'minimum fit'. Whilst it is recognised that such practices might be sensible and commonplace in many organisations who achieve the default /32-/29 allocation we must acknowledge that when operating in the high order bit space we need to be aware of the disproportionate impact that such approaches would have. Even though I may have been vague with the numbers and specifics, does it help shed any light on how we might struggle to fit into a /29 allocation? In many respects, for us I feel that the fact there are >500k /48's in a /29 is similar to the fact that a /64 subnet has 2^64 addresses within it - it doesn't necessarily mean what the figures might otherwise first suggest! Regards, Mathew From ripe-wgs at radu-adrian.feurdean.net Mon May 11 21:32:19 2015 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Mon, 11 May 2015 21:32:19 +0200 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: <20150511185929.GM35191@cilantro.c4inet.net> References: <5550D371.4080505@ripe.net> <5550E3CE.8040103@tvt-datos.es> <5550E616.60503@list.ak.cx> <20150511174531.GK35191@cilantro.c4inet.net> <5550F180.6020702@v4escrow.net> <20150511185929.GM35191@cilantro.c4inet.net> Message-ID: <1431372739.3154620.265935961.2B5710FA@webmail.messagingengine.com> On Mon, May 11, 2015, at 20:59, Sascha Luck [ml] wrote: > it can now be done for 2015-01. So if, next week, the community > decides that all allocations > /22 should never have been made, I > lose the ones I have already? Because it was already done for This is borderline to bad faith. Policy only affect future, and this is also valid for 2015-01. If you made some assumptions in the past and were not yet able to benefit from what you supposed - bad luck/hurry up (2015-01 is not YET policy). If we manage to change some of the *transfer* conditions, it is because the community belives that there's a problem to be solved. Want to see some really retroactive stuff still not considered so ? Spend a few years here in France :) From apwg at c4inet.net Mon May 11 21:44:00 2015 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Mon, 11 May 2015 20:44:00 +0100 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: <1431372739.3154620.265935961.2B5710FA@webmail.messagingengine.com> References: <5550D371.4080505@ripe.net> <5550E3CE.8040103@tvt-datos.es> <5550E616.60503@list.ak.cx> <20150511174531.GK35191@cilantro.c4inet.net> <5550F180.6020702@v4escrow.net> <20150511185929.GM35191@cilantro.c4inet.net> <1431372739.3154620.265935961.2B5710FA@webmail.messagingengine.com> Message-ID: <20150511194400.GN35191@cilantro.c4inet.net> On Mon, May 11, 2015 at 09:32:19PM +0200, Radu-Adrian FEURDEAN wrote: >This is borderline to bad faith. ISTR you not being very happy about being accused on this list, so I would thank you very much, indeed, not to accuse me of acting in bad faith. Yours sincerely, Sascha Luck From stecenkoserj at gmail.com Mon May 11 22:22:35 2015 From: stecenkoserj at gmail.com (Sergey Stecenko) Date: Mon, 11 May 2015 23:22:35 +0300 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: <20150511194400.GN35191@cilantro.c4inet.net> References: <5550D371.4080505@ripe.net> <5550E3CE.8040103@tvt-datos.es> <5550E616.60503@list.ak.cx> <20150511174531.GK35191@cilantro.c4inet.net> <5550F180.6020702@v4escrow.net> <20150511185929.GM35191@cilantro.c4inet.net> <1431372739.3154620.265935961.2B5710FA@webmail.messagingengine.com> <20150511194400.GN35191@cilantro.c4inet.net> Message-ID: Hi all! I don't understand true reasons of this proposal creation. Let's think together. If it was created to interrupt exhaustion of IPv4 blocks, I want retort: today, 11.05.2015 have been allocated 6392 IPv4 from last /8 (last block is 185.99.220.0/22, 256/4=64, 64*99=6336, 6336+224/4=6392) If we go here https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/ipv4-transfers/table-of-transfers press ctrl+F and input 185. we can see 508 results, but we should devide it by 2, due to there are 2 results in one transfer. So there are 254 transfers of IPv4 from the last /8. It is 4% from all allocated IPv4 /8. Also you should draw your attention to some LIRs who make more than 10 transfers every day. Yes, they don't transfer IPs from last /8. But did you think how many resources RIPE can fill if it returns unused resources? May be we will think globaly but don't about how to close a hole doesn't affect IPv4 exhaustion. So I oppose this proposal. 2015-05-11 22:44 GMT+03:00, Sascha Luck [ml] : > On Mon, May 11, 2015 at 09:32:19PM +0200, Radu-Adrian FEURDEAN wrote: >>This is borderline to bad faith. > > ISTR you not being very happy about being accused on this list, > so I would thank you very much, indeed, not to accuse me of > acting in bad faith. > > Yours sincerely, > Sascha Luck > > -- ----- Kind regards, Sergey Stecenko From stecenkoserj at gmail.com Mon May 11 22:10:50 2015 From: stecenkoserj at gmail.com (Sergey Stecenko) Date: Mon, 11 May 2015 23:10:50 +0300 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: <20150511194400.GN35191@cilantro.c4inet.net> References: <5550D371.4080505@ripe.net> <5550E3CE.8040103@tvt-datos.es> <5550E616.60503@list.ak.cx> <20150511174531.GK35191@cilantro.c4inet.net> <5550F180.6020702@v4escrow.net> <20150511185929.GM35191@cilantro.c4inet.net> <1431372739.3154620.265935961.2B5710FA@webmail.messagingengine.com> <20150511194400.GN35191@cilantro.c4inet.net> Message-ID: Hi all! I don't understand true reasons of this proposal creation. Let's think together. If it was created to interrupt exhaustion of IPv4 blocks, I want retort: today, 11.05.2015 have been allocated 6392 IPv4 from last /8 Last block is 185.99.220.0/22, 256/4=64, 64*99=6336, 6336+224/4=6392 If we go here https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/ipv4-transfers/table-of-transfers press ctrl+F and input 185. we can see 508 results, but we should devide it by 2, due to there are 2 results in one transfer. So there are 254 transfers of IPv4 from the last /8. It is 4% from all allocated IPv4 /8. Also you should draw your attention to some LIRs who make more than 10 transfers every day. Yes, they don't transfer IPs from last /8. But did you think how many resources RIPE can fill if it returns unused resources? May be we will think globaly but don't about how to close a hole doesn't affect IPv4 exhaustion. So I oppose this proposal. 2015-05-11 22:44 GMT+03:00, Sascha Luck [ml] : > On Mon, May 11, 2015 at 09:32:19PM +0200, Radu-Adrian FEURDEAN wrote: >>This is borderline to bad faith. > > ISTR you not being very happy about being accused on this list, > so I would thank you very much, indeed, not to accuse me of > acting in bad faith. > > Yours sincerely, > Sascha Luck > > -- ----- Kind regards, Sergey Stecenko From stecenkoserj at gmail.com Mon May 11 22:29:57 2015 From: stecenkoserj at gmail.com (Sergey Stecenko) Date: Mon, 11 May 2015 23:29:57 +0300 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: References: <5550D371.4080505@ripe.net> <5550E3CE.8040103@tvt-datos.es> <5550E616.60503@list.ak.cx> <20150511174531.GK35191@cilantro.c4inet.net> <5550F180.6020702@v4escrow.net> <20150511185929.GM35191@cilantro.c4inet.net> <1431372739.3154620.265935961.2B5710FA@webmail.messagingengine.com> <20150511194400.GN35191@cilantro.c4inet.net> Message-ID: Exuse me about two same emails. It was bag in my client 2015-05-11 23:22 GMT+03:00, Sergey Stecenko : > Hi all! > > I don't understand true reasons of this proposal creation. > > Let's think together. If it was created to interrupt exhaustion of > IPv4 blocks, I want retort: > today, 11.05.2015 have been allocated 6392 IPv4 from last /8 > (last block is 185.99.220.0/22, 256/4=64, 64*99=6336, 6336+224/4=6392) > > If we go here > https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/ipv4-transfers/table-of-transfers > press ctrl+F and input 185. we can see 508 results, but we should > devide it by 2, due to there are 2 results in one transfer. So there > are 254 transfers of IPv4 from the last /8. It is 4% from all > allocated IPv4 /8. > > Also you should draw your attention to some LIRs who make more than 10 > transfers every day. Yes, they don't transfer IPs from last /8. But > did you think how many resources RIPE can fill if it returns unused > resources? May be we will think globaly but don't about how to close a > hole doesn't affect IPv4 exhaustion. > > So I oppose this proposal. > > 2015-05-11 22:44 GMT+03:00, Sascha Luck [ml] : >> On Mon, May 11, 2015 at 09:32:19PM +0200, Radu-Adrian FEURDEAN wrote: >>>This is borderline to bad faith. >> >> ISTR you not being very happy about being accused on this list, >> so I would thank you very much, indeed, not to accuse me of >> acting in bad faith. >> >> Yours sincerely, >> Sascha Luck >> >> > > > -- > ----- > Kind regards, > Sergey Stecenko > -- ----- Kind regards, Sergey Stecenko From ip at infinitytelecom.ro Tue May 12 01:18:17 2015 From: ip at infinitytelecom.ro (Infinity Telecom SRL) Date: Tue, 12 May 2015 02:18:17 +0300 Subject: [address-policy-wg] address-policy-wg Digest, Vol 45, Issue 8 In-Reply-To: <91DA37C68BCB47B6A78299EAE80C9D0E@gmail.com> References: <91DA37C68BCB47B6A78299EAE80C9D0E@gmail.com> Message-ID: <588413966.20150512021817@infinitytelecom.ro> Hello Callum, No comments.. because no one wants the true here. -- Best regards, Gabriel Voitis -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkennedy at libertyglobal.com Tue May 12 08:13:38 2015 From: jkennedy at libertyglobal.com (Kennedy, James) Date: Tue, 12 May 2015 06:13:38 +0000 Subject: [address-policy-wg] address-policy-wg Digest, Vol 45, Issue 8 In-Reply-To: <588413966.20150512021817@infinitytelecom.ro> References: <91DA37C68BCB47B6A78299EAE80C9D0E@gmail.com>, <588413966.20150512021817@infinitytelecom.ro> Message-ID: <98D70C5C-DC4D-44A4-8560-A8444B401C3C@upcbroadband.com> Well done to Callum for highlighting this issue. I also commend the /22 hoarding discussion. More should be done to address blatant RIPE abuse for monetary gain. Turning a blind eye is quite alarming. Regards, James Sent from my iPhone On 12 May 2015, at 01:18, "Infinity Telecom SRL" > wrote: Hello Callum, No comments.. because no one wants the true here. -- Best regards, Gabriel Voitis From gert at space.net Tue May 12 09:53:29 2015 From: gert at space.net (Gert Doering) Date: Tue, 12 May 2015 09:53:29 +0200 Subject: [address-policy-wg] address-policy-wg Digest, Vol 45, Issue 8 In-Reply-To: <98D70C5C-DC4D-44A4-8560-A8444B401C3C@upcbroadband.com> References: <91DA37C68BCB47B6A78299EAE80C9D0E@gmail.com> <588413966.20150512021817@infinitytelecom.ro> <98D70C5C-DC4D-44A4-8560-A8444B401C3C@upcbroadband.com> Message-ID: <20150512075329.GS54385@Space.Net> Hi, On Tue, May 12, 2015 at 06:13:38AM +0000, Kennedy, James wrote: > Well done to Callum for highlighting this issue. I also commend > the /22 hoarding discussion. More should be done to address blatant > RIPE abuse for monetary gain. Turning a blind eye is quite alarming. Well, it's two different aspects that are mixed together here. One is "people managed to get large chunks of address space before the last-/8 policy kicked in, and got rich selling them" (Jump SRL is another example of this). There is not really anything we in address policy can do about this retroactively - and in any case, this is something that will certainly not happen again, as there are no big chunks to be received anymore (but of course the NCC will look into it if fraud happened, and the tax authorities might also be interested...) The other one is something we actually *can* do something as address policy community - reduce ongoing(!) unintended usage ("abuse") of the last-/8 policy. So here we are, and discuss 2015-01 :-) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From mschmidt at ripe.net Tue May 12 10:23:36 2015 From: mschmidt at ripe.net (Marco Schmidt) Date: Tue, 12 May 2015 10:23:36 +0200 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: <5550E6F3.70702@tvt-datos.es> References: <5550D371.4080505@ripe.net> <5550E3CE.8040103@tvt-datos.es> <5550E616.60503@list.ak.cx> <5550E6F3.70702@tvt-datos.es> Message-ID: <5551B888.2050004@ripe.net> Hi Daniel, Thanks for your questions. The proposal would only put into place a 24 month holding period for allocations that were made by the RIPE NCC. For allocations that are transferred between LIRs, an identical (24 month) holding period already exists. It has already been mentioned on the mailing list, but I would like to confirm that the RIPE NCC would not revert any previous transfers if the proposal is accepted. But for all new transfer requests, the RIPE NCC would check that at least 24 months had elapsed since the allocation was originally made. I hope this helps. Kind regards Marco Schmidt Policy Development Officer RIPE NCC On 11/05/15 19:29, Daniel Baeza (Red y Sistemas TVT) wrote: > Hi > > El 11/05/2015 a las 19:25, Andre Keller escribi?: >> Hi, >> >> On 11.05.2015 19:15, Daniel Baeza (Red y Sistemas TVT) wrote: >>> It will be retroactive? How this will be handled? >> >> If my interpretation of the IA is correct, the retroactive part is >> restricted to evaluation of transfer requests. It means if/once the >> policy is implemented, it applies to resources already allocated by RIPE >> NCC but not yet transferred. Resources already transferred wont be >> affected. I think this is a sensible approach. > > Quoting Marco: > > >The proposal would apply to allocations that were made in the past. > >Whenthe RIPE NCC received a transfer request, we would check to see > >that at least 24 months had elapsed since the allocation was made. > For >example, a /22 allocation that was made 23 months before the > proposal >was accepted would have a waiting period of one month before > it could >be transferred. > > What kind of allocations is talking Marco about? RIPE to LIR or LIR to > LIR? > > Regards, > > From richih.mailinglist at gmail.com Tue May 12 11:04:34 2015 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Tue, 12 May 2015 11:04:34 +0200 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: <20150511174531.GK35191@cilantro.c4inet.net> References: <5550D371.4080505@ripe.net> <5550E3CE.8040103@tvt-datos.es> <5550E616.60503@list.ak.cx> <20150511174531.GK35191@cilantro.c4inet.net> Message-ID: On Mon, May 11, 2015 at 7:45 PM, Sascha Luck [ml] wrote: > This sets a precedent for changing *everything else* in > this document and applying the changes retrospectively. I can't > be the only one who does not want to go there? They are not affecting existing assignments. They are affecting how transfers of existing assignments are handled. This, to me, is a fundamental difference. Richard From gert at space.net Tue May 12 11:10:53 2015 From: gert at space.net (Gert Doering) Date: Tue, 12 May 2015 11:10:53 +0200 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: <5550E6F3.70702@tvt-datos.es> References: <5550D371.4080505@ripe.net> <5550E3CE.8040103@tvt-datos.es> <5550E616.60503@list.ak.cx> <5550E6F3.70702@tvt-datos.es> Message-ID: <20150512091053.GU54385@Space.Net> Hi, On Mon, May 11, 2015 at 07:29:23PM +0200, Daniel Baeza (Red y Sistemas TVT) wrote: > What kind of allocations is talking Marco about? RIPE to LIR or LIR to LIR? *Allocation* is a well-defined term that is strictly RIPE NCC -> LIR Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From richih.mailinglist at gmail.com Tue May 12 11:33:26 2015 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Tue, 12 May 2015 11:33:26 +0200 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: References: <5550D371.4080505@ripe.net> <5550E3CE.8040103@tvt-datos.es> <5550E616.60503@list.ak.cx> <20150511174531.GK35191@cilantro.c4inet.net> Message-ID: On Tue, May 12, 2015 at 11:04 AM, Richard Hartmann wrote: > They are not affecting existing assignments. I meant allocations of course. Sorry for the noise, Richard From frettled at gmail.com Tue May 12 13:28:39 2015 From: frettled at gmail.com (Jan Ingvoldstad) Date: Tue, 12 May 2015 13:28:39 +0200 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: <20150511171938.GI35191@cilantro.c4inet.net> References: <20150511091036.GB54385@Space.Net> <20150511171938.GI35191@cilantro.c4inet.net> Message-ID: On Mon, May 11, 2015 at 7:19 PM, Sascha Luck [ml] wrote: > On Mon, May 11, 2015 at 03:58:46PM +0200, Jan Ingvoldstad wrote: > >> As Nick states, "I'd be interested to see a real life addressing plan >> which >> needed more than this amount of bit space." I'd actually be interested to >> see a real life addressing plan that needed a /32 bit address space, where >> the need isn't constructed based on the mere possibility of getting that >> space instead of merely e.g. a few hundre million times of the entire IPv4 >> space. >> > > The way I read the proposal, it is not about assignment sizes but > about a "aggregation" vs "conservation" conflict. The proponents have, > AIUI, a problem where they might not fully > assign a /32 or /29 allocation but have different routing > policies for parts of their network, which cannot be satisfied > without violating s3.4 of ripe-641. Apparently, my point was not very reader friendly, so I'll try again: Routing-wise, someone with 64 billion billion billion addresses, have about 16 billion billion ways to route the entire IPv4 internet, within the address space constraints of a /32 allocation. Even if we pretend that it's an extremely useful and necessary thing to have a /64 per end user, so that each end user can enumerate and route the entire EUI-64 space, a /32 is still the same as the entire IPv4 space. That there is a "need" for allocating as much as a /32 in the first place is a design failure in how the addressing segmentation has been handled, in my opinion. It's the IPv4 /8 allocation mistake all over again. Also, as I said, and obviously have to repeat for some people: that cat is out of the bag. It is what it is. But there is no need to compound this design failure. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From frettled at gmail.com Tue May 12 13:32:53 2015 From: frettled at gmail.com (Jan Ingvoldstad) Date: Tue, 12 May 2015 13:32:53 +0200 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: References: <20150511091036.GB54385@Space.Net> <5550A9BB.3020403@inex.ie> Message-ID: On Mon, May 11, 2015 at 9:27 PM, Mathew Newton < Mathew.Newton643 at official.mod.uk> wrote: (..., yes, I read it all) Even though I may have been vague with the numbers and specifics, does it > help shed any light on how we might struggle to fit into a /29 allocation? > In many respects, for us I feel that the fact there are >500k /48's in a > /29 is similar to the fact that a /64 subnet has 2^64 addresses within it - > it doesn't necessarily mean what the figures might otherwise first suggest! > This makes me curious. Your /29 is the equivalent of 8 IPv4 internets, if we ignore that /64 subnet thing. How do you manage your IPv4 space, then? Do you actually have routing that needs more than 8 total IPv4 spaces? -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mathew.Newton643 at official.mod.uk Tue May 12 14:26:43 2015 From: Mathew.Newton643 at official.mod.uk (Mathew Newton) Date: Tue, 12 May 2015 12:26:43 +0000 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: References: <20150511091036.GB54385@Space.Net> <5550A9BB.3020403@inex.ie> Message-ID: Hi Jan, -----Original Message----- > From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Jan Ingvoldstad > Sent: 12 May 2015 12:33 > How do you manage your IPv4 space, then? Not wishing to sound flippant, but the answer to that really is 'with some difficulty'. This is despite being in the fortunate position of holding a /8 IPv4 allocation (amongst other, smaller, ranges) in addition to widespread usage of (overlapping) RFC1918 address space. > Do you actually have routing that needs more than 8 total IPv4 spaces? I cannot answer that directly because it is, in my view, a false dichotomy as it is far more complicated a situation than that. Besides which, migration to IPv6 would be a wasted opportunity if it was rolled out and configured in exactly the same way as IPv4 given all the existing problems and constraints that would continue to persist. Regards, Mathew From apwg at c4inet.net Tue May 12 14:34:22 2015 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Tue, 12 May 2015 13:34:22 +0100 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: References: <20150511091036.GB54385@Space.Net> <20150511171938.GI35191@cilantro.c4inet.net> Message-ID: <20150512123422.GO35191@cilantro.c4inet.net> On Tue, May 12, 2015 at 01:28:39PM +0200, Jan Ingvoldstad wrote: >Apparently, my point was not very reader friendly, so I'll try again: >Routing-wise, someone with 64 billion billion billion addresses, have about >16 billion billion ways to route the entire IPv4 internet, within the >address space constraints of a /32 allocation. In theory, yes. But the policy currently contradicts itself to an extent. Section 3.8 of ripe-641 clearly states: "In IPv6 address policy, the goal of aggregation is considered to be the most important." ss3.4 and 3.5 bear that out also. Yet, s5.1.2 seems to exclude aggregation as a valid reason for an allocation. The Proposal merely attempts to remove this contradiction. rgds, Sascha Luck From frettled at gmail.com Tue May 12 15:09:16 2015 From: frettled at gmail.com (Jan Ingvoldstad) Date: Tue, 12 May 2015 15:09:16 +0200 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: <20150512123422.GO35191@cilantro.c4inet.net> References: <20150511091036.GB54385@Space.Net> <20150511171938.GI35191@cilantro.c4inet.net> <20150512123422.GO35191@cilantro.c4inet.net> Message-ID: On Tue, May 12, 2015 at 2:34 PM, Sascha Luck [ml] wrote: > On Tue, May 12, 2015 at 01:28:39PM +0200, Jan Ingvoldstad wrote: > >> Apparently, my point was not very reader friendly, so I'll try again: >> Routing-wise, someone with 64 billion billion billion addresses, have >> about >> 16 billion billion ways to route the entire IPv4 internet, within the >> address space constraints of a /32 allocation. >> > > In theory, yes. But the policy currently contradicts itself to an > extent. > > Section 3.8 of ripe-641 clearly states: "In IPv6 address policy, > the goal of aggregation is considered to be the most important." > ss3.4 and 3.5 bear that out also. > > Yet, s5.1.2 seems to exclude aggregation as a valid reason for an > allocation. The Proposal merely attempts to remove this > contradiction. Well, yes, that's why I first wrote "This change makes sense ? I support it". -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From apwg at c4inet.net Tue May 12 15:14:49 2015 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Tue, 12 May 2015 14:14:49 +0100 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: References: <20150511091036.GB54385@Space.Net> <20150511171938.GI35191@cilantro.c4inet.net> <20150512123422.GO35191@cilantro.c4inet.net> Message-ID: <20150512131449.GP35191@cilantro.c4inet.net> On Tue, May 12, 2015 at 03:09:16PM +0200, Jan Ingvoldstad wrote: >Well, yes, that's why I first wrote "This change makes sense >??? I support it". -- Jan Oh yes, so you did. Should have read further up in the thread... cheers, Sascha Luck From frettled at gmail.com Tue May 12 15:18:15 2015 From: frettled at gmail.com (Jan Ingvoldstad) Date: Tue, 12 May 2015 15:18:15 +0200 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: References: <20150511091036.GB54385@Space.Net> <5550A9BB.3020403@inex.ie> Message-ID: On Tue, May 12, 2015 at 2:26 PM, Mathew Newton < Mathew.Newton643 at official.mod.uk> wrote: > Hi Jan, > Hi again, Matthew, and thanks for answering. > > -----Original Message----- > > From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On > Behalf Of Jan Ingvoldstad > > Sent: 12 May 2015 12:33 > > > How do you manage your IPv4 space, then? > > Not wishing to sound flippant, but the answer to that really is 'with some > difficulty'. This is despite being in the fortunate position of holding a > /8 IPv4 allocation (amongst other, smaller, ranges) in addition to > widespread usage of (overlapping) RFC1918 address space. > > > Do you actually have routing that needs more than 8 total IPv4 spaces? > > I cannot answer that directly because it is, in my view, a false dichotomy > as it is far more complicated a situation than that. What it does give you, is the opportunity to create 2048 times the amount of routes you could in your current IPv4 /8, without worrying about the things you could do in your internal networks with the remaining part of the /64. Besides which, migration to IPv6 would be a wasted opportunity if it was > rolled out and configured in exactly the same way as IPv4 given all the > existing problems and constraints that would continue to persist. > Oh, I agree with that. Over here, we actively abuse the system by randomly generating /80 addresses for internal use, and reusing those in ways that apparently never were intended by those who designed the IPv6 address specification. What I do think is a problem, though, is that IPv6 address space is considered so plentiful that we're repeating the mistakes of when we thought the IPv4 address space was plentiful. I don't see a big problem with RIPE NCC evaluating requests for allocations up to e.g. /24 in some very rare cases. However, these things have a way of sliding down a slippery slope, and the IPv6 address space is most likely what we're going to be stuck with for our systems' lifetimes. The prospective system lifetimes are long, perhaps on the order of hundreds of years. And that's actually something we need to keep in mind when setting policy today. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Tue May 12 15:36:19 2015 From: gert at space.net (Gert Doering) Date: Tue, 12 May 2015 15:36:19 +0200 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: <20150511174531.GK35191@cilantro.c4inet.net> References: <5550D371.4080505@ripe.net> <5550E3CE.8040103@tvt-datos.es> <5550E616.60503@list.ak.cx> <20150511174531.GK35191@cilantro.c4inet.net> Message-ID: <20150512133619.GB54385@Space.Net> Hi, On Mon, May 11, 2015 at 06:45:31PM +0100, Sascha Luck [ml] wrote: > Your interpretation is the same as mine, correct or not ;) The > crux is, though: it changes ripe-623, the "IPv4 Address > Allocation and Assignment Policies for the RIPE NCC Service > Region" document, not a hypothetical "Transfer Policies" > document. This sets a precedent for changing *everything else* in > this document and applying the changes retrospectively. I can't > be the only one who does not want to go there? Actually, I disagree with your interpretation. Allocation policy is not changed - people will still be able to get new allocations under the same rules, and existing allocations will not be taken away either. Section 5.5 is "Transfer Policy", even if it is contained in the same document as "Allocation Policy" - and it only affects transfers that happen to be after it is implemented, not retroactively. Now, people do get resources with certain assumptions(!) of what they might want to do with them in the future, or what they *can* do with them in the future. Like, "I have this /25 PI space, I can route this on the Internet!". We do not make guarantees that people's assumptions hold. If changing policy to require a holding time breaks the assumption "I can transfer away this block right away" - well, I think this is fully intentional, no? Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From Mathew.Newton643 at official.mod.uk Tue May 12 15:59:26 2015 From: Mathew.Newton643 at official.mod.uk (Mathew Newton) Date: Tue, 12 May 2015 13:59:26 +0000 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: References: <20150511091036.GB54385@Space.Net> <5550A9BB.3020403@inex.ie> Message-ID: -----Original Message----- > From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Jan Ingvoldstad > Sent: 12 May 2015 14:18 > Hi again, Matthew, and thanks for answering. No problem at all - it is good to have this sort of open discussion and whilst it risks drifting off-topic I do fully concede that a proposal such as this cannot be divorced from the general issue of IPv6 addressing, usage and conservation etc. > What I do think is a problem, though, is that IPv6 address space is considered so plentiful that we're repeating the mistakes of when we > thought the IPv4 address space was plentiful. Understood. There is always the risk of the proverbial '640k is enough for anyone' situation occurring. Analogies can be dangerous however if the nuances that set the situations apart aren't given due consideration. > However, these things have a way of sliding down a slippery slope, and the IPv6 address space is most likely what we're going to be stuck > with for our systems' lifetimes. The prospective system lifetimes are long, perhaps on the order of hundreds of years. > > And that's actually something we need to keep in mind when setting policy today. I do fully take your point, and in making this proposal I have no desire to ride roughshod over this very valid concern. 'Finding the balance' is the key even if that might be difficult, not least given that success or otherwise can only be determined at some point in the future and perhaps only with the benefit of hindsight. On the subject of balance however, I cannot ignore the fact that we cannot realistically progress with meaningful IPv6 migration until a reasonably mature addressing strategy (with associated allocation to support it) is in place. Regards, Mathew From frettled at gmail.com Tue May 12 16:07:00 2015 From: frettled at gmail.com (Jan Ingvoldstad) Date: Tue, 12 May 2015 16:07:00 +0200 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: References: <20150511091036.GB54385@Space.Net> <5550A9BB.3020403@inex.ie> <863204E2-9F97-420A-B965-D772F0538363@ecs.soton.ac.uk> Message-ID: On Tue, May 12, 2015 at 3:40 PM, Tim Chown wrote: > > We?re to date only allocating from 1/8th of the overall IPv6 address space. > Which is actually an immensely huge part of it. > There?s 7/8ths remaining in which policy can be changed, if required. > Yes, fortunately. > > And I would put a bet on IPv6 not being the mainstream global / > interplanetary communication protocol in hundreds of years, but I won?t be > around to collect, so?. > Perhaps it won't, but if it won't, then the IPv6 design has failed. IPv4 already has been around for 34 years or so (IIRC, we got it in 1981), and will be something we have to work with for a couple of decades or more, depending on whether IPv6 actually can replace IPv6 use that quickly. So let's say, for simplicity's sake, that IPv4's lifetime turns out to be 50-60 years. If IPv6 shouldn't be the mainstream communication protocol for the timeframe I mentioned, someone had best get started on IPv7. > > On the /64 boundary, I?d point you at RFC7421. > Well, I guess that's a nice document to point people to, if they're unfamiliar with the history of IPv6 and the issues that have been raised. I'll be sure to mention it if I run into someone who needs it, thanks! -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From apwg at c4inet.net Tue May 12 16:51:06 2015 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Tue, 12 May 2015 15:51:06 +0100 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: <20150512133619.GB54385@Space.Net> References: <5550D371.4080505@ripe.net> <5550E3CE.8040103@tvt-datos.es> <5550E616.60503@list.ak.cx> <20150511174531.GK35191@cilantro.c4inet.net> <20150512133619.GB54385@Space.Net> Message-ID: <20150512145106.GQ35191@cilantro.c4inet.net> On Tue, May 12, 2015 at 03:36:19PM +0200, Gert Doering wrote: >Now, people do get resources with certain assumptions(!) of what they >might want to do with them in the future, or what they *can* do with them >in the future. Like, "I have this /25 PI space, I can route this on >the Internet!". We do not make guarantees that people's assumptions hold That is what scares me about this. If there is a policy passed that restricts all end-user assignments to max. /29 and it is implemented affecting existing assignments, I am (and all other LIRs in the region are) to disconnect and re-number all my customers? I believe a LIR should have a reasonable assumption of continuity when dealing with a monopoly provider. >If changing policy to require a holding time breaks the assumption >"I can transfer away this block right away" - well, I think this is >fully intentional, no? It breaks assumptions that were perfectly reasonable a year ago. Also, I'm pretty sure those who would abuse a loophole are following this debate and will have their transfers well sorted before the implementation date (if they have any sense). Implementing this policy for existing allocations will probably only affect a small number of LIRs who are acting in good faith. existing allocations will only affect rgds, Sascha Luck From gert at space.net Tue May 12 17:01:58 2015 From: gert at space.net (Gert Doering) Date: Tue, 12 May 2015 17:01:58 +0200 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: <20150512145106.GQ35191@cilantro.c4inet.net> References: <5550D371.4080505@ripe.net> <5550E3CE.8040103@tvt-datos.es> <5550E616.60503@list.ak.cx> <20150511174531.GK35191@cilantro.c4inet.net> <20150512133619.GB54385@Space.Net> <20150512145106.GQ35191@cilantro.c4inet.net> Message-ID: <20150512150158.GG54385@Space.Net> Hi, On Tue, May 12, 2015 at 03:51:06PM +0100, Sascha Luck [ml] wrote: > On Tue, May 12, 2015 at 03:36:19PM +0200, Gert Doering wrote: > >Now, people do get resources with certain assumptions(!) of what they > >might want to do with them in the future, or what they *can* do with them > >in the future. Like, "I have this /25 PI space, I can route this on > >the Internet!". We do not make guarantees that people's assumptions hold > > That is what scares me about this. If there is a policy > passed that restricts all end-user assignments to max. /29 > and it is implemented affecting existing assignments, I am (and > all other LIRs in the region are) to disconnect and re-number all my > customers? But this is *not* "affecting existing assignments or allocations", as far as "holding this allocation and number your stuff with it" (which should be the primary usage for a block of IP addresses) goes. It is affecting *new* activities that a LIR might or might not start with their allocation in the future (namely: transfer it away). (And indeed, back in the day, we did change the rules what a LIR might do regarding assignments - from "do what you want" to "you have an assignment window, and anything larger than that needs NCC approval" - and then again, with a default AW of a /22. Worked out, as it was the same rules for everyone(!) - but as well, it only affected new activities not "what you have stays where it is", so no assignment or allocations became invalid due to it, and neither does this one) [..] > >If changing policy to require a holding time breaks the assumption > >"I can transfer away this block right away" - well, I think this is > >fully intentional, no? > > It breaks assumptions that were perfectly reasonable a year ago. Actually while it was "according to the letter of the policy", I think it will be hard to find someone to actually say "it was according to the spirit of the last-/8 policy". So I'd challenge the "reasonable" in your statement. > Also, I'm pretty sure those who would abuse a loophole are > following this debate and will have their transfers well sorted > before the implementation date (if they have any sense). Implementing > this policy for existing allocations will probably only affect a > small number of LIRs who are acting in good faith. Well, so you say "it will not stop the bad guys from doing their stuff in the next few months, so we should not do it at all, so they can keep up the business for the next years", am I understanding this correctly? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From farmer at umn.edu Tue May 12 17:21:53 2015 From: farmer at umn.edu (David Farmer) Date: Tue, 12 May 2015 10:21:53 -0500 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: References: <20150511091036.GB54385@Space.Net> <5550A9BB.3020403@inex.ie> <863204E2-9F97-420A-B965-D772F0538363@ecs.soton.ac.uk> Message-ID: <034023C0-909B-41B8-8B05-56768BCC1E98@umn.edu> > On May 12, 2015, at 09:07, Jan Ingvoldstad wrote: > >> On Tue, May 12, 2015 at 3:40 PM, Tim Chown wrote: >> ..... >> On the /64 boundary, I?d point you at RFC7421. > > > Well, I guess that's a nice document to point people to, if they're unfamiliar with the history of IPv6 and the issues that have been raised. I'll be sure to mention it if I run into someone who needs it, thanks! I'd like to call you attention to the following paragraph from the end of section 2 of RFC7421; The remainder of this document describes arguments that have been made against the current fixed IID length and analyzes the effects of a possible change. However, the consensus of the IETF is that the benefits of keeping the length fixed at 64 bits and the practical difficulties of changing it outweigh the arguments for change. The point being that neither RIPE nor the other RIRs are the place to discuss changes to the IPv6 architecture. If you feel changes to the IPv6 architecture needed, you need to participate in discussions in the IETF v6ops and 6man working groups. It would have been helpful to have added your voice in the the discussion of the Why64 draft that became RFC 7421. There was a lively discussion, but the paragraph above accurately reflects the current consensus. Participation in the discussion at the IETF is really the only way to change that consensus. Thanks -- =============================================== 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 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjc at ecs.soton.ac.uk Tue May 12 15:40:46 2015 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Tue, 12 May 2015 14:40:46 +0100 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: References: <20150511091036.GB54385@Space.Net> <5550A9BB.3020403@inex.ie> <863204E2-9F97-420A-B965-D772F0538363@ecs.soton.ac.uk> Message-ID: Hi, > On 12 May 2015, at 14:18, Jan Ingvoldstad wrote: > > On Tue, May 12, 2015 at 2:26 PM, Mathew Newton > wrote: > Hi Jan, > > Hi again, Matthew, and thanks for answering. > > > -----Original Message----- > > From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net ] On Behalf Of Jan Ingvoldstad > > Sent: 12 May 2015 12:33 > > > How do you manage your IPv4 space, then? > > Not wishing to sound flippant, but the answer to that really is 'with some difficulty'. This is despite being in the fortunate position of holding a /8 IPv4 allocation (amongst other, smaller, ranges) in addition to widespread usage of (overlapping) RFC1918 address space. > > > Do you actually have routing that needs more than 8 total IPv4 spaces? > > I cannot answer that directly because it is, in my view, a false dichotomy as it is far more complicated a situation than that. > > What it does give you, is the opportunity to create 2048 times the amount of routes you could in your current IPv4 /8, without worrying about the things you could do in your internal networks with the remaining part of the /64. > > Besides which, migration to IPv6 would be a wasted opportunity if it was rolled out and configured in exactly the same way as IPv4 given all the existing problems and constraints that would continue to persist. > > Oh, I agree with that. Over here, we actively abuse the system by randomly generating /80 addresses for internal use, and reusing those in ways that apparently never were intended by those who designed the IPv6 address specification. > > What I do think is a problem, though, is that IPv6 address space is considered so plentiful that we're repeating the mistakes of when we thought the IPv4 address space was plentiful. > > I don't see a big problem with RIPE NCC evaluating requests for allocations up to e.g. /24 in some very rare cases. > > However, these things have a way of sliding down a slippery slope, and the IPv6 address space is most likely what we're going to be stuck with for our systems' lifetimes. The prospective system lifetimes are long, perhaps on the order of hundreds of years. > > And that's actually something we need to keep in mind when setting policy today. We?re to date only allocating from 1/8th of the overall IPv6 address space. There?s 7/8ths remaining in which policy can be changed, if required. And I would put a bet on IPv6 not being the mainstream global / interplanetary communication protocol in hundreds of years, but I won?t be around to collect, so?. On the /64 boundary, I?d point you at RFC7421. Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From apwg at c4inet.net Tue May 12 17:41:47 2015 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Tue, 12 May 2015 16:41:47 +0100 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: <20150512150158.GG54385@Space.Net> References: <5550D371.4080505@ripe.net> <5550E3CE.8040103@tvt-datos.es> <5550E616.60503@list.ak.cx> <20150511174531.GK35191@cilantro.c4inet.net> <20150512133619.GB54385@Space.Net> <20150512145106.GQ35191@cilantro.c4inet.net> <20150512150158.GG54385@Space.Net> Message-ID: <20150512154147.GR35191@cilantro.c4inet.net> On Tue, May 12, 2015 at 05:01:58PM +0200, Gert Doering wrote: >Actually while it was "according to the letter of the policy", I >think it will be hard to find someone to actually say "it was >according to the spirit of the last-/8 policy". So I'd >challenge the "reasonable" in your statement. A LIR now joining the RIPE NCC has no way of determining what the "spirit" of a policy is. (bar, perhaps, reading all apwg discussions leading to it) The letter of the document is all that counts and IPRAs can't make determinations based on the "spirit" either, otherwise this proposal would not be necessary. So, yes, an assumption that one can join the NCC now and get a /22 with the intent to "sell" it is reasonable. Much as the assumption that one can join the NCC now and receive a /22 to assign it to customers, is. There are already ideas - in this very discussion - about forcing LIRs to return all v4 space not already assigned and, if that ever becomes a proposal, this very discussion will be used to argue that that would not be retroactive. >Well, so you say "it will not stop the bad guys from doing their >stuff in the next few months, so we should not do it at all, so >they can keep up the business for the next years", am I >understanding this correctly? I'm saying that endangering a lot of innocents - via an, in my opinion, dangerous precedent - is too high a price to pay to catch a limited number of "baddies". For the record, before I get accused of acting in bad faith again, I have no dog in this race. I'm not managing any allocations that are either up for transfer or, ttbomk, younger than 2 years. rgds, Sascha Luck From richih.mailinglist at gmail.com Tue May 12 17:43:59 2015 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Tue, 12 May 2015 17:43:59 +0200 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: <20150512150158.GG54385@Space.Net> References: <5550D371.4080505@ripe.net> <5550E3CE.8040103@tvt-datos.es> <5550E616.60503@list.ak.cx> <20150511174531.GK35191@cilantro.c4inet.net> <20150512133619.GB54385@Space.Net> <20150512145106.GQ35191@cilantro.c4inet.net> <20150512150158.GG54385@Space.Net> Message-ID: On Tue, May 12, 2015 at 5:01 PM, Gert Doering wrote: > It is affecting *new* activities that a LIR might or might not start > with their allocation in the future (namely: transfer it away). Trying to keep the noise level low: I agree strongly with this and with everything else Gert has said in this and his prior email. Richard From springer at inlandnet.com Tue May 12 18:35:36 2015 From: springer at inlandnet.com (John Springer) Date: Tue, 12 May 2015 09:35:36 -0700 (PDT) Subject: [address-policy-wg] New on RIPE Labs: IPv4 Transfers in the RIPE NCC Service Region In-Reply-To: References: <554A25E4.7060108@ripe.net> <895536294.20150507210413@infinitytelecom.ro> <20150508115414.GA23553@danton.fire-world.de> Message-ID: agree. John Springer On Fri, 8 May 2015, remco van mook wrote: > Three years and one day ago, I wrote on this very list: > > "...Personally I'm rather sick and tired of hearing people say 'yes, let's?break IPv4 so we all MUST move to IPv6'. > If you think this is good policy or even good engineering, please think again. It will make us end up with a broken > internet that, surprise, we won't be managing any more. Breaking IPv4 might lead to increased IPv6 adoption, but not > on the internet as we know it today. Everybody who wants to connect his organisation to the internet is going to need > at least some IPv4 address space for the time being, so why screw it up for new entrants?..." > > Whether this is about reinventing final /8 or about people making money on IPv4 transfers does not make one jot of a > difference. > > > Remco > > (no hats) > > > > On Fri, May 8, 2015 at 1:54 PM Sebastian Wiesinger wrote: > * Dan L?dtke [2015-05-08 11:33]: > > See, we can not win this games. Let?s stop wasting energy and > > resources on dealing with legacy IP and how to make it work for a > > bit longer. New entrants are entering are market that is not fair, > > and we can not make a real difference. The only way forward is to > > push IPv6 and restore a healthy climate regarding the availability > > of IP addresses. > > Dan, > > if you don't want to invest your time trying to make this market more > fair by all means go ahead and do something else. There are still > people here who would like to try so that new players can enter a > market that will be dominated by IPv4 for some time to come. > > Most people here are pushing IPv6 but as much as you want to bury IPv4 > it will still be around for some time. > > Regards > > Sebastian > > -- > GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A? 9D82 58A2 D94A 93A0 B9CE) > 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. > ? ? ? ? ? ? -- Terry Pratchett, The Fifth Elephant > > > From ripe-wgs.cs at schiefner.de Tue May 12 20:14:52 2015 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Tue, 12 May 2015 20:14:52 +0200 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: References: Message-ID: <5552431C.6020205@schiefner.de> +1 On 11.05.2015 13:43, Marco Schmidt wrote: > Dear colleagues, > > > The draft document for the proposal described in 2015-01, "Alignment of Transfer > Requirements for IPv4 Allocations" has been published. > > The impact analysis that was conducted for this proposal has also been published. > > You can find the full proposal and the impact analysis at: > > https://www.ripe.net/participate/policies/proposals/2015-01 > > and the draft document at: > > https://www.ripe.net/participate/policies/proposals/2015-01/draft > > We encourage you to review this proposal and send your comments to > address-policy-wg at ripe.net before 9 June 2015. > > > Regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC From frettled at gmail.com Tue May 12 22:20:38 2015 From: frettled at gmail.com (Jan Ingvoldstad) Date: Tue, 12 May 2015 22:20:38 +0200 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: <20150512154147.GR35191@cilantro.c4inet.net> References: <5550D371.4080505@ripe.net> <5550E3CE.8040103@tvt-datos.es> <5550E616.60503@list.ak.cx> <20150511174531.GK35191@cilantro.c4inet.net> <20150512133619.GB54385@Space.Net> <20150512145106.GQ35191@cilantro.c4inet.net> <20150512150158.GG54385@Space.Net> <20150512154147.GR35191@cilantro.c4inet.net> Message-ID: On 12. mai 2015, at 17.41, Sascha Luck [ml] wrote: > >> On Tue, May 12, 2015 at 05:01:58PM +0200, Gert Doering wrote: >> Actually while it was "according to the letter of the policy", I >> think it will be hard to find someone to actually say "it was >> according to the spirit of the last-/8 policy". So I'd >> challenge the "reasonable" in your statement. > > A LIR now joining the RIPE NCC has no way of determining what the > "spirit" of a policy is. (bar, perhaps, reading all apwg > discussions leading to it) The letter of the document is all that > counts and IPRAs can't make determinations based on the "spirit" > either, otherwise this proposal would not be necessary. You have a point about the spirit of the policy not necessarily being clear from the policy's text. That said, I find it hard to read the current policy in a way where you could reasonably make the assumptions you make a case for defending. The document isn't limited to a 5.5 that stands on its own, and anyone reading this point alone cannot honestly claim to act in good faith. Additionally, the loophole in the policy is a clear discrepancy, one which an interested party would ask for clarification about and not merely pretend wasn't there. Going along the route you've chosen therefore seems somewhat disingenuous to me, sorry. -- Cheers, Jan From gert at space.net Tue May 12 23:24:56 2015 From: gert at space.net (Gert Doering) Date: Tue, 12 May 2015 23:24:56 +0200 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: References: <20150511091036.GB54385@Space.Net> <5550A9BB.3020403@inex.ie> Message-ID: <20150512212456.GQ54385@Space.Net> Hi, On Tue, May 12, 2015 at 03:18:15PM +0200, Jan Ingvoldstad wrote: > And that's actually something we need to keep in mind when setting policy > today. Actually, I am (and I'm having an wary eye on the community :-) ). But I *do* the math. We're inside the very first /12 ever assigned to the NCC, and that is inside the FP 001 - so comparing the number of possible consumers of "huge address blocks" (MoDs, incumbents, ...) - basically, "a few per country in the RIPE region", totalling "a few hundred" - with the number of /24s inside the /12 (4096), this seems to be withing acceptable bounds (well, split the /12 into 2048 /24s and 65000 /29s, so "there is still enough for smaller LIRs"). And if the /12 fills up, we have 507 left inside FP001. And if *that* fills up, we get 6 more tries on a more conservative side. So, yes, I think we're making good use of the available space, but we're not overdoing it... Gert Doering -- community member -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From sander at steffann.nl Wed May 13 09:49:51 2015 From: sander at steffann.nl (Sander Steffann) Date: Wed, 13 May 2015 09:49:51 +0200 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: <20150512154147.GR35191@cilantro.c4inet.net> References: <5550D371.4080505@ripe.net> <5550E3CE.8040103@tvt-datos.es> <5550E616.60503@list.ak.cx> <20150511174531.GK35191@cilantro.c4inet.net> <20150512133619.GB54385@Space.Net> <20150512145106.GQ35191@cilantro.c4inet.net> <20150512150158.GG54385@Space.Net> <20150512154147.GR35191@cilantro.c4inet.net> Message-ID: Hi Sasha, > A LIR now joining the RIPE NCC has no way of determining what the > "spirit" of a policy is. (bar, perhaps, reading all apwg > discussions leading to it) The letter of the document is all that > counts and IPRAs can't make determinations based on the "spirit" > either, otherwise this proposal would not be necessary. > So, yes, an assumption that one can join the NCC now and get a > /22 with the intent to "sell" it is reasonable. The policy actually says that "The LIR must confirm it will make assignment(s) from the allocation". See https://www.ripe.net/publications/docs/ripe-643#51. This is not the case if the intent is to sell the prefix. Cheers, Sander From modonovan at btireland.net Wed May 13 11:43:30 2015 From: modonovan at btireland.net (Mick O Donovan) Date: Wed, 13 May 2015 10:43:30 +0100 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: References: Message-ID: <20150513094329.GA9904@carra.btireland.net> On Tue, Apr 28, 2015 at 02:00:40PM +0200, Marco Schmidt wrote: > > Dear colleagues, > > A proposed change to the RIPE Document "IPv6 Address Allocation and Assignment Policy" now is open for discussion. > > The proposal aims to expand the criteria for evaluating initial IPv6 allocations larger than a /29. The RIPE NCC would consider additional aspects beyond only the number of existing users and extent of the organisation's infrastructure. > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2015-03 > > We encourage you to review this proposal and send your comments to before 27 May 2015. > > Regards > > Marco Schmidt > Policy Development Officer > RIPE NCC > > Having listened to the rationale in person for this proposal I would give tentative support to this proposal on the basis that the request provides appropriate justification. I also agree with Benedict's comment on the mic about ensuring that the allocation is required to be so large by virtue of an address plan for instance. Regards, Mick -- Mick O'Donovan | Network Engineer | BT Ireland | Website: http://www.btireland.net Looking Glass: http://lg.as2110.net Peering Record: http://as2110.peeringdb.com AS-SET Macro: AS-BTIRE | ASN: 2110 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: Digital signature URL: From rogerj at gmail.com Wed May 13 11:56:25 2015 From: rogerj at gmail.com (=?UTF-8?Q?Roger_J=C3=B8rgensen?=) Date: Wed, 13 May 2015 11:56:25 +0200 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: References: <20150511091036.GB54385@Space.Net> <5550A9BB.3020403@inex.ie> <863204E2-9F97-420A-B965-D772F0538363@ecs.soton.ac.uk> Message-ID: On Tue, May 12, 2015 at 4:07 PM, Jan Ingvoldstad wrote: > On Tue, May 12, 2015 at 3:40 PM, Tim Chown wrote: >> >> And I would put a bet on IPv6 not being the mainstream global / >> interplanetary communication protocol in hundreds of years, but I won?t be >> around to collect, so?. > > > Perhaps it won't, but if it won't, then the IPv6 design has failed. IPv4 > already has been around for 34 years or so (IIRC, we got it in 1981), and > will be something we have to work with for a couple of decades or more, > depending on whether IPv6 actually can replace IPv6 use that quickly. So > let's say, for simplicity's sake, that IPv4's lifetime turns out to be 50-60 > years. > > If IPv6 shouldn't be the mainstream communication protocol for the timeframe > I mentioned, someone had best get started on IPv7. Are work being done in several forums on interplanetary communication, both with thoughts on delay and on address space. AFAIK some of it is already in production to using IPv6... wish my memory worked today so I could remember where I saw that discussion :-( -- Roger Jorgensen | ROJO9-RIPE rogerj at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From frettled at gmail.com Wed May 13 12:10:10 2015 From: frettled at gmail.com (Jan Ingvoldstad) Date: Wed, 13 May 2015 12:10:10 +0200 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: References: <20150511091036.GB54385@Space.Net> <5550A9BB.3020403@inex.ie> <863204E2-9F97-420A-B965-D772F0538363@ecs.soton.ac.uk> Message-ID: On Wed, May 13, 2015 at 11:56 AM, Roger J?rgensen wrote: > > > Are work being done in several forums on interplanetary communication, > both with thoughts on delay and on address space. AFAIK some of it is > already in production to using IPv6... wish my memory worked today so > I could remember where I saw that discussion :-( > > In the more immediate future, I think the main concern will be IOT-related. (IOT = Internet of Things) While this is a bit of a lame buzzword now, something on the scale of what Manfred Macx et al have in the early chapters of Charles Stross's Accelerando, may very well be how things work in a couple of decades. It's hard to predict. In any case, what's most important to us now, is to at least be aware of the potential challenges, and not enact policies that will make the future much more difficult. And, again, I don't think the proposal discussed here poses such a problem. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastian at karotte.org Wed May 13 12:15:45 2015 From: sebastian at karotte.org (Sebastian Wiesinger) Date: Wed, 13 May 2015 12:15:45 +0200 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: References: Message-ID: <20150513101545.GA3398@danton.fire-world.de> * Marco Schmidt [2015-05-11 13:48]: > > Dear colleagues, > > > The draft document for the proposal described in 2015-01, "Alignment of Transfer > Requirements for IPv4 Allocations" has been published. > > The impact analysis that was conducted for this proposal has also been published. Let's do this. The proposal will prevent a lot of what is going on today especially with the M&A changes that the executive board did come up with. Everyone can see the allocation numbers in the RIPE Labs article. The number of LIRs closed on member request in 2014 is as high as the *whole* amount of LIRs closed in the years before. The amount of LIRs closed in 2014 as a whole more than doubled from 2013. This abuse of the last-/8 policy is only going to get worse and I think it will accelerate in speed. We can always extend the policy to close other loopholes later if they come up. But right now I think we should stop this behaviour ASAP. This counts as support. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 616 bytes Desc: Digital signature URL: From Mathew.Newton643 at official.mod.uk Wed May 13 14:14:21 2015 From: Mathew.Newton643 at official.mod.uk (Mathew Newton) Date: Wed, 13 May 2015 12:14:21 +0000 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: References: Message-ID: Dear WG, As one of the authors behind 2015-03 please accept my apologies for not being able to attend today's AP WG session, and a particularly apology (and thanks!) to Alexander for letting him have to take the virtual stage and face the questions by himself! I would like to respond to a query raised by a gentleman in the audience (apologies I couldn't catch the name) regarding, if I understood correctly, a concern that the large allocations that the policy proposal is intended to provide for may lead to growth in the Internet routing table. Whilst I cannot speak for anyone's IPv6 addressing strategy but the UK MOD's I can confirm that concern over routing table growth was one of the key drivers behind the requirement for what ends up being a large allocation as the hierarchy and aggregation that this affords us mean we can summarise external routes far more easily than would otherwise be possible. Whilst the policy proposal is not intended to cater solely for the UK MOD, and therefore I want to try and stay clear of discussing issues specific to the UK MOD if at all possible (happy to try and do so when requested/required though), I can understand if there are specific concerns about an allocation being made to what is such a large and complex organisation like ours - and a relatively unique one at that. However, I should highlight that given the security constraints and connectivity requirements of the environment we operate in the vast majority of external routing announcements will only be visible to coalition partners (other nations' military networks, NATO infrastructure, etc) and will not appear in the routing tables of what you might call the 'publicly visible' portion of the Internet. The general point still stands though - aggregation and summarisation is (and should be) key regardless of how much equivalent address space is being allocated. Perhaps I have misunderstood the comment/concern? Happy to continue the discussion either way though. Regards, Mathew P.S. I am not au fait with the etiquette of this mailing list - should specific sub-discussions of a given proposal be split off with their own subject line? From apwg at c4inet.net Wed May 13 15:51:48 2015 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Wed, 13 May 2015 14:51:48 +0100 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: References: <5550D371.4080505@ripe.net> <5550E3CE.8040103@tvt-datos.es> <5550E616.60503@list.ak.cx> <20150511174531.GK35191@cilantro.c4inet.net> <20150512133619.GB54385@Space.Net> <20150512145106.GQ35191@cilantro.c4inet.net> <20150512150158.GG54385@Space.Net> <20150512154147.GR35191@cilantro.c4inet.net> Message-ID: <20150513135148.GT35191@cilantro.c4inet.net> On Tue, May 12, 2015 at 10:20:38PM +0200, Jan Ingvoldstad wrote: >Going along the route you've chosen therefore seems somewhat >disingenuous to me, sorry. Ad hominem, the last refuge of the argument-less. You lose. yours, Sascha Luck From elvis at v4escrow.net Wed May 13 15:57:35 2015 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Wed, 13 May 2015 15:57:35 +0200 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: <20150513135148.GT35191@cilantro.c4inet.net> References: <5550D371.4080505@ripe.net> <5550E3CE.8040103@tvt-datos.es> <5550E616.60503@list.ak.cx> <20150511174531.GK35191@cilantro.c4inet.net> <20150512133619.GB54385@Space.Net> <20150512145106.GQ35191@cilantro.c4inet.net> <20150512150158.GG54385@Space.Net> <20150512154147.GR35191@cilantro.c4inet.net> <20150513135148.GT35191@cilantro.c4inet.net> Message-ID: <5553584F.3050409@v4escrow.net> I really dislike the personal attacks caused by the discussions on this policy proposal. Please stop. thanks, elvis On 13/05/15 15:51, Sascha Luck [ml] wrote: > On Tue, May 12, 2015 at 10:20:38PM +0200, Jan Ingvoldstad wrote: >> Going along the route you've chosen therefore seems somewhat >> disingenuous to me, sorry. > > Ad hominem, the last refuge of the argument-less. You lose. > > yours, > Sascha Luck > -- Elvis Daniel Velea Chief Executive Officer Email: elvis at V4Escrow.net US Phone: +1 (702) 475 5914 EU Phone: +31 (0) 61458 1914 Recognised IPv4 Broker/Facilitator in: This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received this email in error, please notify the sender immediately and delete the original.Any other use of this email is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 5043 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1.png Type: image/png Size: 11971 bytes Desc: not available URL: From frettled at gmail.com Wed May 13 16:02:26 2015 From: frettled at gmail.com (Jan Ingvoldstad) Date: Wed, 13 May 2015 16:02:26 +0200 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: <20150513135148.GT35191@cilantro.c4inet.net> References: <5550D371.4080505@ripe.net> <5550E3CE.8040103@tvt-datos.es> <5550E616.60503@list.ak.cx> <20150511174531.GK35191@cilantro.c4inet.net> <20150512133619.GB54385@Space.Net> <20150512145106.GQ35191@cilantro.c4inet.net> <20150512150158.GG54385@Space.Net> <20150512154147.GR35191@cilantro.c4inet.net> <20150513135148.GT35191@cilantro.c4inet.net> Message-ID: On Wed, May 13, 2015 at 3:51 PM, Sascha Luck [ml] wrote: > On Tue, May 12, 2015 at 10:20:38PM +0200, Jan Ingvoldstad wrote: > >> Going along the route you've chosen therefore seems somewhat >> disingenuous to me, sorry. >> > > Ad hominem, the last refuge of the argument-less. You lose. > I'm sorry, the intent of attacking the argument by calling it disingenuous was NOT to attack you as a person. It was meant as an attack on the argument itself. Again, my apologies. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Wed May 13 16:24:14 2015 From: sander at steffann.nl (Sander Steffann) Date: Wed, 13 May 2015 16:24:14 +0200 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: <20150513132615.GS35191@cilantro.c4inet.net> References: <5550D371.4080505@ripe.net> <5550E3CE.8040103@tvt-datos.es> <5550E616.60503@list.ak.cx> <20150511174531.GK35191@cilantro.c4inet.net> <20150512133619.GB54385@Space.Net> <20150512145106.GQ35191@cilantro.c4inet.net> <20150512150158.GG54385@Space.Net> <20150512154147.GR35191@cilantro.c4inet.net> <20150513132615.GS35191@cilantro.c4inet.net> Message-ID: <4FA99F20-4BBE-4F1B-9658-D6E86D0F46D1@steffann.nl> Hi, > A good point and one that hadn't occurred to me. If this was to > be interpreted as "must make assignments", would this proposal > even be necessary? Everyone receiving resources and immediately > transferring them would be in violation of the policy and, > strictly speaking, all transfers of this kind that have already > happened would be invalid? My argument was mainly to point out that this behaviour is against the spirit of the policy, in response to: > So, yes, an assumption that one can join the NCC now and get a /22 with the intent to "sell" it is reasonable. But yes, if no assignments happened at all I agree that the allocation would not be according to policy. However, people trying to cheat the system could just make fake assignments for a short period of time and then they would strictly speaking comply with the policy. They would still be dishonest though, which is why I feel that we shouldn't take this practice into account when writing new policy. If you want to look up the history of this, here is the message from Tore when he introduced that line in the policy: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2013-August/008155.html Cheers, Sander From apwg at c4inet.net Wed May 13 16:36:58 2015 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Wed, 13 May 2015 15:36:58 +0100 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: References: <5550E3CE.8040103@tvt-datos.es> <5550E616.60503@list.ak.cx> <20150511174531.GK35191@cilantro.c4inet.net> <20150512133619.GB54385@Space.Net> <20150512145106.GQ35191@cilantro.c4inet.net> <20150512150158.GG54385@Space.Net> <20150512154147.GR35191@cilantro.c4inet.net> <20150513135148.GT35191@cilantro.c4inet.net> Message-ID: <20150513143658.GU35191@cilantro.c4inet.net> On Wed, May 13, 2015 at 04:02:26PM +0200, Jan Ingvoldstad wrote: >It was meant as an attack on the argument itself. No worries. Interpretative difficulties, this proposal seems to attract them :) I'll re-state my arguments at this point, for the avoidance of doubt: - I recognise that a loop-hole exists and that some people are getting away with something - I'm *not* trying to defend outright abuse of such loop-holes. - I don't oppose attempts to prevent outright speculative behaviour. - I don't believe those attempts are going to be terribly effective, they are going to make speculation somewhat more expensive, nothing more - I fear, also in light of what I've seen from the apwg session today, that these attempts will lead to more bureaucratisation and attempts of the "community" to regulate into the business affairs of members and that those will also extend into the ipv6 realm. - I believe that the freedom of members to determine their own business affairs is an important good, and one worth balancing against the desire to not let anyone get away with "gaming the policy" - I believe the implementation plan for 2015-01 does not strike this balance properly and that it sets a dangerous precedent for more of the same which is already in the pipeline. rgds, Sascha Luck From ripe at opteamax.de Wed May 13 17:12:19 2015 From: ripe at opteamax.de (Opteamax GmbH) Date: Wed, 13 May 2015 17:12:19 +0200 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: <20150513094329.GA9904@carra.btireland.net> References: <20150513094329.GA9904@carra.btireland.net> Message-ID: <555369D3.2050703@opteamax.de> On 13.05.2015 11:43, Mick O Donovan wrote: > Having listened to the rationale in person for this proposal I would > give tentative support to this proposal on the basis that the request > provides appropriate justification. At this point I want to mention, that NCC-Staff is doing (and have always been doing) a very good job reviewing requests for resources. And although I was kind of p*ssed on one or another request back because of not good enough formulated justification, I am happy that they did it. Thanks for this! For the ones asking for more conservation: I know a bunch of LIRs who received a /29, as /29 currently does not need any justification. I also know that those LIR will never ever use more than a /48 or /40 ... so if we care that much about conservation now, I am sure that those few (we are currently talking about 10 Requests and about 45 currently allocated <= /28) requesters of larger V6-Space are nothing against the amount of /29 assignments which will never be used. Best regards -- Jens Ott Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo at opteamax.de HRB: 23144, Amtsgericht Montabaur Umsatzsteuer-ID.: DE264133989 From gert at space.net Thu May 14 12:11:38 2015 From: gert at space.net (Gert Doering) Date: Thu, 14 May 2015 12:11:38 +0200 Subject: [address-policy-wg] 2015-02 New Policy Proposal (Keep IPv6 PI When Requesting IPv6 Allocation) In-Reply-To: References: Message-ID: <20150514101138.GA75064@Space.Net> Dear AP WG, On Tue, Apr 14, 2015 at 02:52:58PM +0200, Marco Schmidt wrote: > A proposed change to RIPE Document "IPv6 Address Allocation and Assignment Policy" > is now available for discussion. > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2015-02 > > We encourage you to review this proposal and send your comments to > before 13 May 2015. Discussion phase is over. This proposal certainly wins the prize for having collected the highest number of supporting voices *ever* (and nothing else!), so we move forward to impact analysis, and then discussion phase. Marco will do the formal announcements. Gert Doering -- your friendly junior APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From nick at inex.ie Thu May 14 14:56:10 2015 From: nick at inex.ie (Nick Hilliard) Date: Thu, 14 May 2015 14:56:10 +0200 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: References: <20150511091036.GB54385@Space.Net> <5550A9BB.3020403@inex.ie> Message-ID: <55549B6A.50304@inex.ie> Hi Mathew, yes, it was a question and thanks for answering it! It is clear that there are some larger organisations who fall outside the scope of the existing policy and that a policy change may be a good idea. Nick On 11/05/2015 21:27, Mathew Newton wrote: > Hi Nick, > >> -----Original Message----- From: address-policy-wg >> [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Nick >> Hilliard Sent: 11 May 2015 14:08 >> >> On 11/05/2015 11:10, Gert Doering wrote: >>> I see "/32 as default, up to /29 if you ask" as very reasonable >>> middle ground... >> >> /29 gives 2^19 /48s, or a little over 500k /48s or 134 million /56s. >> >> Before supporting this proposal, I'd be interested to see a real life >> addressing plan which needed more than this amount of bit space. > > That is a perfectly reasonable question to ask (assuming it was > effectively a question!). My difficulty however is adequately answering > it without inadvertently releasing too much information about the UK > MOD's infrastructure to a public mailing list. That is no one's problem > but my own though so let me see how far I can get by at least covering > some of the key principles. > > One clarification to get out of the way first given that this branch of > the thread was a slight diversion from the core topic is that I am not > looking at changing the '/32 as default, up to /29 if you ask' position > as, like Gert, I agree that this is a very sensible default position. > The issue presented is how to deal with those organisations who cannot > fit within a /29, of which the UK MOD is one... > > As context for those not familiar, the UK MOD and Armed Forces are a > large and complex organisation with an annual budget of over ?37 billion > (?52 billion) which puts it in the world's 'top 5' militaries by such a > measure. Its global IP infrastructure spans land, sea, air and space > environments using practically all conceivable physical layer transport > type. > > From an IPv6 addressing perspective, the best place to start is arguably > with the end sites. There are 10's of thousands of end sites > encompassing what you might regard as 'conventional' sites > (office/corporate environments, datacentres, military bases, dockyards > etc) as well as military platforms (tanks, aircraft, ships etc) some of > which could be regarded as enterprises in their own right (e.g. aircraft > carriers). > > These end sites achieve their wider connectivity via ISPs (generally, > but not exclusively, 'private' ISPs whose services are exclusive to the > UK MOD) of which there are hundreds in each different geographic > operating area (fixed UK, fixed overseas, deployed etc). Most end sites > would connect to multiple ISPs, either simultaneously or varying over > time (long term infrastructure changes down to short term connectivity > changes in support of operations) and there is expected to be a mix of > how to deal with this from an addressing perspective (readdressing, > multiple prefixes, mobile IP, etc). > > In order to achieve aggregation and efficiency of routing (within the > MOD, to other nations' militaries and to the Internet) this 'geographic > area > ISP > end site' hierarchy becomes a key part of the addressing > strategy. It is not a flat network and cannot be treated as one by the > addressing strategy hence a straightforward 'number of end sites' > calculation does not result in sufficient address space to be > allocated. > > The issue is further compounded by the fact that the UK MOD must abide > by national security policy which requires that ALL information that is > generated, collected, stored, processed or shared is afforded the > appropriate degree of protection according to its sensitivity and level > of threat it faces. Security classifications are used to categorise the > different levels of sensitivity/threat and effective delivery of these > lead to the requirement to operate completely independent > infrastructures with discrete routing policies for each classification > hence multiple allocations are effectively required. > > The option of 'luxuries' such as semantics, nibble boundaries, 'just in > case' expansion bits etc do not feature in the UK MOD's IPv6 addressing > strategy - it is very much a 'minimum fit'. Whilst it is recognised that > such practices might be sensible and commonplace in many organisations > who achieve the default /32-/29 allocation we must acknowledge that when > operating in the high order bit space we need to be aware of the > disproportionate impact that such approaches would have. > > Even though I may have been vague with the numbers and specifics, does > it help shed any light on how we might struggle to fit into a /29 > allocation? In many respects, for us I feel that the fact there are > >500k /48's in a /29 is similar to the fact that a /64 subnet has 2^64 > addresses within it - it doesn't necessarily mean what the figures might > otherwise first suggest! > > Regards, > > Mathew > From mschmidt at ripe.net Thu May 14 15:11:55 2015 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 14 May 2015 15:11:55 +0200 Subject: [address-policy-wg] 2015-02 Impact Analysis will be produced (Keep IPv6 PI When Requesting IPv6 Allocation) Message-ID: Dear colleagues, The discussion period for the proposal described in 2015-02, "Keep IPv6 PI When Requesting IPv6 Allocation" has ended. The RIPE NCC Impact Analysis will now be prepared for review. We will publish the document shortly and we will make an announcement. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2015-02 Regards Marco Schmidt Policy Development Officer RIPE NCC From gert at space.net Fri May 15 14:34:01 2015 From: gert at space.net (Gert Doering) Date: Fri, 15 May 2015 14:34:01 +0200 Subject: [address-policy-wg] 2014-03 Review Period extended until 19 May 2015 (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: References: Message-ID: <20150515123401.GA15231@Space.Net> Dear AP WG, On Mon, Mar 09, 2015 at 04:57:20PM +0100, Marco Schmidt wrote: > The Review Period for the proposal 2014-03, "Remove Multihoming Requirement for > AS Number Assignments" has been extended until 19 May 2015. So - we extended this to wait for the AGM decision on "charging for AS numbers". The AGM decided, and the clear majority decide to not introduce annual charges for AS numbers - my life would be easier otherwise, but this is what was decided, so respect it and see how we can achive our goals here :-) Feedback for this proposal so far was, if I simplify a bit - we want to take care not to exhaust 16bit-ASNs - there is unlimited number of 32bit ASNs (but there *also* was feedback about "N. from I. could go out and register all 4 billion 32bit ASNs, and exhaust the system"... now what?) - we might want a garbage collection / reclamation mechanism - the current policy text is too complicate, arbitrary numbers are bad but there *is* quite a bit of support for the generic idea of "loosen up the rules for 32bit ASNs, as the multihoming requirement is often hard or impossible to demonstrate or check". So, what should we (or, more precise, the proposers) do to get there? Nick, I'm actually looking at you since you threw the most sand into the gears here... some specific suggestions how you'd tackle this would be welcome. (Technically, I see no other way than to change text and do another round of IA/review phase with the feedback we've received until now - if, based on the new background from AGM, everybody who has objected so far is now accepting this at it stands to go forward - please say so!) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From nick at inex.ie Sat May 16 01:40:13 2015 From: nick at inex.ie (Nick Hilliard) Date: Sat, 16 May 2015 00:40:13 +0100 Subject: [address-policy-wg] 2014-03 Review Period extended until 19 May 2015 (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <20150515123401.GA15231@Space.Net> References: <20150515123401.GA15231@Space.Net> Message-ID: <555683DD.3010605@inex.ie> Gert, On 15/05/2015 13:34, Gert Doering wrote: > Feedback for this proposal so far was, if I simplify a bit > > - we want to take care not to exhaust 16bit-ASNs > - there is unlimited number of 32bit ASNs > (but there *also* was feedback about "N. from I. could go out and > register all 4 billion 32bit ASNs, and exhaust the system"... now what?) > > - we might want a garbage collection / reclamation mechanism > > - the current policy text is too complicate, arbitrary numbers are bad > > but there *is* quite a bit of support for the generic idea of "loosen up > the rules for 32bit ASNs, as the multihoming requirement is often hard > or impossible to demonstrate or check". I'm going to suggest taking a step back and looking at the problem from a distance so that we can get a better view of how to approach it. We have two generic categories of assignment policy in the RIPE region: needs-based and entitlement-based. - needs-based policies operate on the basis of a stated requirement of some form, where this requirement undergoes some form of evaluation. - entitlement-based assignment operates on the principal that if you request a resource of some form within particular parameters, you will get the resource with no requirement to justify it. If you stray outside the specified parameters, then one of two things happens: either a needs-based policy will apply or the request will be denied by policy. Needs-based policies have historically worked well for constrained resources (ipv4 and ASNs). On the other hand where a resource is abundant, these policies can be cumbersome or unnecessary. In terms of resource run-out, ASN16s will be gone sooner or later, pretty much no matter what policy is put in place. Conversely, the supply of ASN32s is not constrained; nor is it likely to be in future. We have an ASN transfer policy, which is good. The questions relevant to creating a new policy for handling ASN assignments are: - would it be useful to implement an asn16 runout policy? - outside that, is there a need to have separate policies for ASN16s and ASN32s? - for all these cases, would it be best to use needs-based policies, entitlement-based policies or something else? - if it's appropriate to put in a needs-based policy, can we define what "need" is? e.g. would it be useful to collate a set of use-cases that the RIPE NCC could use to evaluate requests? - if an entitlement-based policy is implemented, is it an unlimited entitlement policy, or does it transform to a needs-based or a deny based policy outside specific parameters? No doubt I have left many important things out. If the answers to these questions suggest that we need a new policy, we need also need to evaluate whether the new policy which results is better than the existing one, for some meaning of the word "better". Nick From David.Huberman at microsoft.com Sat May 16 04:33:34 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Sat, 16 May 2015 02:33:34 +0000 Subject: [address-policy-wg] 2014-03 Review Period extended until 19 May 2015 (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <555683DD.3010605@inex.ie> References: <20150515123401.GA15231@Space.Net> <555683DD.3010605@inex.ie> Message-ID: In reply to Nick Hilliard's post this evening, I wanted to share some data. In AS8075 (Microsoft's primary network), we have a lot of incompatibility with 4-byte AS numbers. We have equipment from some vendors who don't support it at all (like Arista), or support it without being able to remove-private on the extended range (important for locally-unique AS number usage) We've filed feature requests with all parties, and our spend with these vendors should justify fast tracking feature requests. And yet ... nothing here in May 2015. RFC4893 was published EIGHT years ago, and vendors are just not all that far along. If the RIRs don't do anything to preserve 2-byte AS numbers, then things are going to start really breaking. That should get vendors to wake up. But that's not a good scenario. On the other hand, there's no stopping 2-byte exhaustion: the velocity of 2-byte number registration is too fast - we'll be out soon enough no matter what we do. David R Huberman Principal, Global IP Addressing Microsoft Corporation > -----Original Message----- > From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On > Behalf Of Nick Hilliard > Sent: Friday, May 15, 2015 4:40 PM > To: Gert Doering; address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] 2014-03 Review Period extended until 19 > May 2015 (Remove Multihoming Requirement for AS Number Assignments) > > Gert, > > On 15/05/2015 13:34, Gert Doering wrote: > > Feedback for this proposal so far was, if I simplify a bit > > > > - we want to take care not to exhaust 16bit-ASNs > > - there is unlimited number of 32bit ASNs > > (but there *also* was feedback about "N. from I. could go out and > > register all 4 billion 32bit ASNs, and exhaust the system"... now > > what?) > > > > - we might want a garbage collection / reclamation mechanism > > > > - the current policy text is too complicate, arbitrary numbers are > > bad > > > > but there *is* quite a bit of support for the generic idea of "loosen > > up the rules for 32bit ASNs, as the multihoming requirement is often > > hard or impossible to demonstrate or check". > > I'm going to suggest taking a step back and looking at the problem from a > distance so that we can get a better view of how to approach it. > > We have two generic categories of assignment policy in the RIPE region: > needs-based and entitlement-based. > > - needs-based policies operate on the basis of a stated requirement of some > form, where this requirement undergoes some form of evaluation. > > - entitlement-based assignment operates on the principal that if you request > a resource of some form within particular parameters, you will get the > resource with no requirement to justify it. If you stray outside the specified > parameters, then one of two things happens: either a needs-based policy > will apply or the request will be denied by policy. > > Needs-based policies have historically worked well for constrained resources > (ipv4 and ASNs). On the other hand where a resource is abundant, these > policies can be cumbersome or unnecessary. > > In terms of resource run-out, ASN16s will be gone sooner or later, pretty > much no matter what policy is put in place. Conversely, the supply of ASN32s > is not constrained; nor is it likely to be in future. > > We have an ASN transfer policy, which is good. > > The questions relevant to creating a new policy for handling ASN assignments > are: > > - would it be useful to implement an asn16 runout policy? > > - outside that, is there a need to have separate policies for ASN16s and > ASN32s? > > - for all these cases, would it be best to use needs-based policies, > entitlement-based policies or something else? > > - if it's appropriate to put in a needs-based policy, can we define what "need" > is? e.g. would it be useful to collate a set of use-cases that the RIPE NCC > could use to evaluate requests? > > - if an entitlement-based policy is implemented, is it an unlimited entitlement > policy, or does it transform to a needs-based or a deny based policy outside > specific parameters? > > No doubt I have left many important things out. > > If the answers to these questions suggest that we need a new policy, we > need also need to evaluate whether the new policy which results is better > than the existing one, for some meaning of the word "better". > > Nick > From ebais at a2b-internet.com Sat May 16 09:11:36 2015 From: ebais at a2b-internet.com (Erik Bais - A2B Internet) Date: Sat, 16 May 2015 09:11:36 +0200 Subject: [address-policy-wg] 2014-03 Review Period extended until 19 May 2015 (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <20150515123401.GA15231@Space.Net> References: <20150515123401.GA15231@Space.Net> Message-ID: <07B9D88D-23CB-45CC-8795-BFC2093F461B@a2b-internet.com> Hi Gert, There are a couple things that I keep reading and hearing in the discussion here.. Run-out of 16 bit as's and garbage collection.. May I suggest to Job to look into the following to see if that would fit his plan moving forward and is in line with what the community thinks is acceptable. ( personally I don't have a specific preferrence ) Exclude the 16 bit AS's from the removal of the multihoming requirement. ( so it stays as it is currently ) and ask the NCC to keep a close look on the number of requested AS's per entity to avoid stockpiling and give them the silent 'right' to question and stop abuse of what we are trying to achieve here. Also the NCC should include resource garbage collection in the ARC's and if that is not enough, report that to the community during the ripe meeting ncc update. The above mentioned suggestion could bring us closer to consensus.. It is not something I have a strong feeling about. It is a suggestion that one can look at. Personally I would go for version 1 of the proposal, no limitations and in addition ask the ncc to look close to any abusive behaviour. Regards, Erik Bais Verstuurd vanaf mijn iPad > Op 15 mei 2015 om 14:34 heeft Gert Doering het volgende geschreven: > > Dear AP WG, > >> On Mon, Mar 09, 2015 at 04:57:20PM +0100, Marco Schmidt wrote: >> The Review Period for the proposal 2014-03, "Remove Multihoming Requirement for >> AS Number Assignments" has been extended until 19 May 2015. > > So - we extended this to wait for the AGM decision on "charging for AS > numbers". The AGM decided, and the clear majority decide to not introduce > annual charges for AS numbers - my life would be easier otherwise, but > this is what was decided, so respect it and see how we can achive our > goals here :-) > > Feedback for this proposal so far was, if I simplify a bit > > - we want to take care not to exhaust 16bit-ASNs > - there is unlimited number of 32bit ASNs > (but there *also* was feedback about "N. from I. could go out and > register all 4 billion 32bit ASNs, and exhaust the system"... now what?) > > - we might want a garbage collection / reclamation mechanism > > - the current policy text is too complicate, arbitrary numbers are bad > > but there *is* quite a bit of support for the generic idea of "loosen up > the rules for 32bit ASNs, as the multihoming requirement is often hard > or impossible to demonstrate or check". > > So, what should we (or, more precise, the proposers) do to get there? > > Nick, I'm actually looking at you since you threw the most sand into the > gears here... some specific suggestions how you'd tackle this would > be welcome. > > (Technically, I see no other way than to change text and do another round > of IA/review phase with the feedback we've received until now - if, based > on the new background from AGM, everybody who has objected so far is now > accepting this at it stands to go forward - please say so!) > > Gert Doering > -- APWG chair > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From ripe at opteamax.de Sat May 16 12:26:15 2015 From: ripe at opteamax.de (Opteamax GmbH) Date: Sat, 16 May 2015 12:26:15 +0200 Subject: [address-policy-wg] 2014-03 Review Period extended until 19 May 2015 (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <07B9D88D-23CB-45CC-8795-BFC2093F461B@a2b-internet.com> References: <20150515123401.GA15231@Space.Net> <07B9D88D-23CB-45CC-8795-BFC2093F461B@a2b-internet.com> Message-ID: <55571B47.8070701@opteamax.de> Erik and all, I think your idea to exclude 16Bit ASN from the proposal brings us much closer to consensus. Nevertheless I think we should start discussing about how to "enhance" garbage collection, but this should IMHO not be part of discussion on _this_ proposal. BR Jens On 16.05.2015 09:11, Erik Bais - A2B Internet wrote: > Hi Gert, > > There are a couple things that I keep reading and hearing in the discussion here.. > > Run-out of 16 bit as's and garbage collection.. > > May I suggest to Job to look into the following to see if that would fit his plan moving forward and is in line with what the community thinks is acceptable. ( personally I don't have a specific preferrence ) > > Exclude the 16 bit AS's from the removal of the multihoming requirement. ( so it stays as it is currently ) and ask the NCC to keep a close look on the number of requested AS's per entity to avoid stockpiling and give them the silent 'right' to question and stop abuse of what we are trying to achieve here. Also the NCC should include resource garbage collection in the ARC's and if that is not enough, report that to the community during the ripe meeting ncc update. > > The above mentioned suggestion could bring us closer to consensus.. It is not something I have a strong feeling about. It is a suggestion that one can look at. > > Personally I would go for version 1 of the proposal, no limitations and in addition ask the ncc to look close to any abusive behaviour. > > Regards, > Erik Bais > > Verstuurd vanaf mijn iPad > >> Op 15 mei 2015 om 14:34 heeft Gert Doering het volgende geschreven: >> >> Dear AP WG, >> >>> On Mon, Mar 09, 2015 at 04:57:20PM +0100, Marco Schmidt wrote: >>> The Review Period for the proposal 2014-03, "Remove Multihoming Requirement for >>> AS Number Assignments" has been extended until 19 May 2015. >> >> So - we extended this to wait for the AGM decision on "charging for AS >> numbers". The AGM decided, and the clear majority decide to not introduce >> annual charges for AS numbers - my life would be easier otherwise, but >> this is what was decided, so respect it and see how we can achive our >> goals here :-) >> >> Feedback for this proposal so far was, if I simplify a bit >> >> - we want to take care not to exhaust 16bit-ASNs >> - there is unlimited number of 32bit ASNs >> (but there *also* was feedback about "N. from I. could go out and >> register all 4 billion 32bit ASNs, and exhaust the system"... now what?) >> >> - we might want a garbage collection / reclamation mechanism >> >> - the current policy text is too complicate, arbitrary numbers are bad >> >> but there *is* quite a bit of support for the generic idea of "loosen up >> the rules for 32bit ASNs, as the multihoming requirement is often hard >> or impossible to demonstrate or check". >> >> So, what should we (or, more precise, the proposers) do to get there? >> >> Nick, I'm actually looking at you since you threw the most sand into the >> gears here... some specific suggestions how you'd tackle this would >> be welcome. >> >> (Technically, I see no other way than to change text and do another round >> of IA/review phase with the feedback we've received until now - if, based >> on the new background from AGM, everybody who has objected so far is now >> accepting this at it stands to go forward - please say so!) >> >> Gert Doering >> -- APWG chair >> -- >> have you enabled IPv6 on something today...? >> >> SpaceNet AG Vorstand: Sebastian v. Bomhard >> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann >> D-80807 Muenchen HRB: 136055 (AG Muenchen) >> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > > !DSPAM:637,5556f3e6233401397117280! > -- Opteamax GmbH - RIPE-Team Jens Ott Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo at opteamax.de HRB: 23144, Amtsgericht Montabaur Umsatzsteuer-ID.: DE264133989 From gert at space.net Sat May 16 12:53:50 2015 From: gert at space.net (Gert Doering) Date: Sat, 16 May 2015 12:53:50 +0200 Subject: [address-policy-wg] 2014-03 Review Period extended until 19 May 2015 (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <55571B47.8070701@opteamax.de> References: <20150515123401.GA15231@Space.Net> <07B9D88D-23CB-45CC-8795-BFC2093F461B@a2b-internet.com> <55571B47.8070701@opteamax.de> Message-ID: <20150516105350.GI54385@Space.Net> Hi, On Sat, May 16, 2015 at 12:26:15PM +0200, Opteamax GmbH wrote: > I think your idea to exclude 16Bit ASN from the proposal brings us much > closer to consensus. I should point out that 16bit ASNs are not currently subject of the proposal anyway... :-) But I did hear what Erik, Nick and David said, and there's a lot of wisdom in it. There will be a round of discussion with the proposers, and I see new text coming up, taking this into account. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From ebais at a2b-internet.com Sat May 16 14:17:33 2015 From: ebais at a2b-internet.com (Erik Bais - A2B Internet) Date: Sat, 16 May 2015 14:17:33 +0200 Subject: [address-policy-wg] 2014-03 Review Period extended until 19 May 2015 (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <55571B47.8070701@opteamax.de> References: <20150515123401.GA15231@Space.Net> <07B9D88D-23CB-45CC-8795-BFC2093F461B@a2b-internet.com> <55571B47.8070701@opteamax.de> Message-ID: <194305A1-1A25-4C75-9F11-45843CB938F9@a2b-internet.com> Hi Jens, As we are talking about AS numbers and implicit about BGP .. Lets take the following approach ... Ask the NCC to use a max-prefix kind of warning system in the hand-out / provisioning software .. A 95% warning level at ( arbitrary number 100 AS nr's ). To start asking questions on what the LIR is doing .. A full stop handing out at the 100% of the $arbitrary-number ... And the NCC will have to manually increase the number by another $amount. Same as every ISP does on an Internet Exchange with $peer that trips their max-prefix number .... That can be implemented in the backend .. And the majority of the LIR's will never trip the max-resource level .. But the ones that do .. Can be directed to the IPRA's and provide additional insight on what the hell they think they are doing ... And if they are not providing a sufficient use case that satisfies the IPRA, their request to increase the $arbitraty-number won't be increased ... So they can't request additional resources. This suggested deployment setup doesn't need to be put in stone in the policy, but as a request to the NCC in the introduction or rationale .. To keep the policy text clear and the NCC can reply to it in their IA .. Just my 2 cents ... Erik Bais. ( now a bit more awake that this morning ) ... > Op 16 mei 2015 om 12:26 heeft Opteamax GmbH het volgende geschreven: > > Erik and all, > > I think your idea to exclude 16Bit ASN from the proposal brings us much > closer to consensus. > > Nevertheless I think we should start discussing about how to "enhance" > garbage collection, but this should IMHO not be part of discussion on > _this_ proposal. > > BR Jens > >> On 16.05.2015 09:11, Erik Bais - A2B Internet wrote: >> Hi Gert, >> >> There are a couple things that I keep reading and hearing in the discussion here.. >> >> Run-out of 16 bit as's and garbage collection.. >> >> May I suggest to Job to look into the following to see if that would fit his plan moving forward and is in line with what the community thinks is acceptable. ( personally I don't have a specific preferrence ) >> >> Exclude the 16 bit AS's from the removal of the multihoming requirement. ( so it stays as it is currently ) and ask the NCC to keep a close look on the number of requested AS's per entity to avoid stockpiling and give them the silent 'right' to question and stop abuse of what we are trying to achieve here. Also the NCC should include resource garbage collection in the ARC's and if that is not enough, report that to the community during the ripe meeting ncc update. >> >> The above mentioned suggestion could bring us closer to consensus.. It is not something I have a strong feeling about. It is a suggestion that one can look at. >> >> Personally I would go for version 1 of the proposal, no limitations and in addition ask the ncc to look close to any abusive behaviour. >> >> Regards, >> Erik Bais >> >> Verstuurd vanaf mijn iPad >> >>> Op 15 mei 2015 om 14:34 heeft Gert Doering het volgende geschreven: >>> >>> Dear AP WG, >>> >>>> On Mon, Mar 09, 2015 at 04:57:20PM +0100, Marco Schmidt wrote: >>>> The Review Period for the proposal 2014-03, "Remove Multihoming Requirement for >>>> AS Number Assignments" has been extended until 19 May 2015. >>> >>> So - we extended this to wait for the AGM decision on "charging for AS >>> numbers". The AGM decided, and the clear majority decide to not introduce >>> annual charges for AS numbers - my life would be easier otherwise, but >>> this is what was decided, so respect it and see how we can achive our >>> goals here :-) >>> >>> Feedback for this proposal so far was, if I simplify a bit >>> >>> - we want to take care not to exhaust 16bit-ASNs >>> - there is unlimited number of 32bit ASNs >>> (but there *also* was feedback about "N. from I. could go out and >>> register all 4 billion 32bit ASNs, and exhaust the system"... now what?) >>> >>> - we might want a garbage collection / reclamation mechanism >>> >>> - the current policy text is too complicate, arbitrary numbers are bad >>> >>> but there *is* quite a bit of support for the generic idea of "loosen up >>> the rules for 32bit ASNs, as the multihoming requirement is often hard >>> or impossible to demonstrate or check". >>> >>> So, what should we (or, more precise, the proposers) do to get there? >>> >>> Nick, I'm actually looking at you since you threw the most sand into the >>> gears here... some specific suggestions how you'd tackle this would >>> be welcome. >>> >>> (Technically, I see no other way than to change text and do another round >>> of IA/review phase with the feedback we've received until now - if, based >>> on the new background from AGM, everybody who has objected so far is now >>> accepting this at it stands to go forward - please say so!) >>> >>> Gert Doering >>> -- APWG chair >>> -- >>> have you enabled IPv6 on something today...? >>> >>> SpaceNet AG Vorstand: Sebastian v. Bomhard >>> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann >>> D-80807 Muenchen HRB: 136055 (AG Muenchen) >>> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 >> >> >> !DSPAM:637,5556f3e6233401397117280! > > > -- > Opteamax GmbH - RIPE-Team > Jens Ott > > Opteamax GmbH > > Simrockstr. 4b > 53619 Rheinbreitbach > > Tel.: +49 2224 969500 > Fax: +49 2224 97691059 > Email: jo at opteamax.de > > HRB: 23144, Amtsgericht Montabaur > Umsatzsteuer-ID.: DE264133989 > From ripe at opteamax.de Sat May 16 14:51:48 2015 From: ripe at opteamax.de (Opteamax GmbH) Date: Sat, 16 May 2015 14:51:48 +0200 Subject: [address-policy-wg] 2014-03 Review Period extended until 19 May 2015 (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <194305A1-1A25-4C75-9F11-45843CB938F9@a2b-internet.com> References: <20150515123401.GA15231@Space.Net> <07B9D88D-23CB-45CC-8795-BFC2093F461B@a2b-internet.com> <55571B47.8070701@opteamax.de> <194305A1-1A25-4C75-9F11-45843CB938F9@a2b-internet.com> Message-ID: <55573D64.6000507@opteamax.de> Hi Erik, I like that idea ... sometimes it might help to ask questions to make some LIRs start reflecting what they are actually doing. (But to be honest I prefer a single LIR requesting 100 ASN over a single person opening 100 LIRs, to bypass that rule and gather some IP-V4 as "side-effect" ;) ) @Gert: you are absolutely right when pointing it out that 16bit actually are already excluded explicitly ... think I was still to (amster)damaged when writing my last mail ... sorry ;) BR Jens On 16.05.2015 14:17, Erik Bais - A2B Internet wrote: > Hi Jens, > > As we are talking about AS numbers and implicit about BGP .. Lets take the following approach ... > > Ask the NCC to use a max-prefix kind of warning system in the hand-out / provisioning software .. > > A 95% warning level at ( arbitrary number 100 AS nr's ). To start asking questions on what the LIR is doing .. A full stop handing out at the 100% of the $arbitrary-number ... And the NCC will have to manually increase the number by another $amount. Same as every ISP does on an Internet Exchange with $peer that trips their max-prefix number .... > > That can be implemented in the backend .. And the majority of the LIR's will never trip the max-resource level .. But the ones that do .. Can be directed to the IPRA's and provide additional insight on what the hell they think they are doing ... And if they are not providing a sufficient use case that satisfies the IPRA, their request to increase the $arbitraty-number won't be increased ... So they can't request additional resources. > > This suggested deployment setup doesn't need to be put in stone in the policy, but as a request to the NCC in the introduction or rationale .. To keep the policy text clear and the NCC can reply to it in their IA .. > > Just my 2 cents ... > > Erik Bais. ( now a bit more awake that this morning ) ... > >> Op 16 mei 2015 om 12:26 heeft Opteamax GmbH het volgende geschreven: >> >> Erik and all, >> >> I think your idea to exclude 16Bit ASN from the proposal brings us much >> closer to consensus. >> >> Nevertheless I think we should start discussing about how to "enhance" >> garbage collection, but this should IMHO not be part of discussion on >> _this_ proposal. >> >> BR Jens >> >>> On 16.05.2015 09:11, Erik Bais - A2B Internet wrote: >>> Hi Gert, >>> >>> There are a couple things that I keep reading and hearing in the discussion here.. >>> >>> Run-out of 16 bit as's and garbage collection.. >>> >>> May I suggest to Job to look into the following to see if that would fit his plan moving forward and is in line with what the community thinks is acceptable. ( personally I don't have a specific preferrence ) >>> >>> Exclude the 16 bit AS's from the removal of the multihoming requirement. ( so it stays as it is currently ) and ask the NCC to keep a close look on the number of requested AS's per entity to avoid stockpiling and give them the silent 'right' to question and stop abuse of what we are trying to achieve here. Also the NCC should include resource garbage collection in the ARC's and if that is not enough, report that to the community during the ripe meeting ncc update. >>> >>> The above mentioned suggestion could bring us closer to consensus.. It is not something I have a strong feeling about. It is a suggestion that one can look at. >>> >>> Personally I would go for version 1 of the proposal, no limitations and in addition ask the ncc to look close to any abusive behaviour. >>> >>> Regards, >>> Erik Bais >>> >>> Verstuurd vanaf mijn iPad >>> >>>> Op 15 mei 2015 om 14:34 heeft Gert Doering het volgende geschreven: >>>> >>>> Dear AP WG, >>>> >>>>> On Mon, Mar 09, 2015 at 04:57:20PM +0100, Marco Schmidt wrote: >>>>> The Review Period for the proposal 2014-03, "Remove Multihoming Requirement for >>>>> AS Number Assignments" has been extended until 19 May 2015. >>>> >>>> So - we extended this to wait for the AGM decision on "charging for AS >>>> numbers". The AGM decided, and the clear majority decide to not introduce >>>> annual charges for AS numbers - my life would be easier otherwise, but >>>> this is what was decided, so respect it and see how we can achive our >>>> goals here :-) >>>> >>>> Feedback for this proposal so far was, if I simplify a bit >>>> >>>> - we want to take care not to exhaust 16bit-ASNs >>>> - there is unlimited number of 32bit ASNs >>>> (but there *also* was feedback about "N. from I. could go out and >>>> register all 4 billion 32bit ASNs, and exhaust the system"... now what?) >>>> >>>> - we might want a garbage collection / reclamation mechanism >>>> >>>> - the current policy text is too complicate, arbitrary numbers are bad >>>> >>>> but there *is* quite a bit of support for the generic idea of "loosen up >>>> the rules for 32bit ASNs, as the multihoming requirement is often hard >>>> or impossible to demonstrate or check". >>>> >>>> So, what should we (or, more precise, the proposers) do to get there? >>>> >>>> Nick, I'm actually looking at you since you threw the most sand into the >>>> gears here... some specific suggestions how you'd tackle this would >>>> be welcome. >>>> >>>> (Technically, I see no other way than to change text and do another round >>>> of IA/review phase with the feedback we've received until now - if, based >>>> on the new background from AGM, everybody who has objected so far is now >>>> accepting this at it stands to go forward - please say so!) >>>> >>>> Gert Doering >>>> -- APWG chair >>>> -- >>>> have you enabled IPv6 on something today...? >>>> >>>> SpaceNet AG Vorstand: Sebastian v. Bomhard >>>> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann >>>> D-80807 Muenchen HRB: 136055 (AG Muenchen) >>>> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 >>> >>> >>> >> >> >> -- >> Opteamax GmbH - RIPE-Team >> Jens Ott >> >> Opteamax GmbH >> >> Simrockstr. 4b >> 53619 Rheinbreitbach >> >> Tel.: +49 2224 969500 >> Fax: +49 2224 97691059 >> Email: jo at opteamax.de >> >> HRB: 23144, Amtsgericht Montabaur >> Umsatzsteuer-ID.: DE264133989 >> > > !DSPAM:637,55573b8463551901918004! > -- Opteamax GmbH - RIPE-Team Jens Ott Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo at opteamax.de HRB: 23144, Amtsgericht Montabaur Umsatzsteuer-ID.: DE264133989 From randy at psg.com Sat May 16 19:13:24 2015 From: randy at psg.com (Randy Bush) Date: Sat, 16 May 2015 07:13:24 -1000 Subject: [address-policy-wg] 2014-03 Review Period extended until 19 May 2015 (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <194305A1-1A25-4C75-9F11-45843CB938F9@a2b-internet.com> References: <20150515123401.GA15231@Space.Net> <07B9D88D-23CB-45CC-8795-BFC2093F461B@a2b-internet.com> <55571B47.8070701@opteamax.de> <194305A1-1A25-4C75-9F11-45843CB938F9@a2b-internet.com> Message-ID: > Ask the NCC to use a max-prefix kind of warning system in the hand-out > / provisioning software .. perhaps there is a relevant lesson from recent discussions of ipv4 last /8 abuse randy From ebais at a2b-internet.com Sat May 16 20:08:12 2015 From: ebais at a2b-internet.com (Erik Bais - A2B Internet) Date: Sat, 16 May 2015 20:08:12 +0200 Subject: [address-policy-wg] 2014-03 Review Period extended until 19 May 2015 (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: References: <20150515123401.GA15231@Space.Net> <07B9D88D-23CB-45CC-8795-BFC2093F461B@a2b-internet.com> <55571B47.8070701@opteamax.de> <194305A1-1A25-4C75-9F11-45843CB938F9@a2b-internet.com> Message-ID: <2E624229-0EFA-4AE4-97D4-020390B83D13@a2b-internet.com> Op 16 mei 2015 om 19:13 heeft Randy Bush het volgende geschreven: >> Ask the NCC to use a max-prefix kind of warning system in the hand-out >> / provisioning software .. > > perhaps there is a relevant lesson from recent discussions of ipv4 last > /8 abuse > > randy We missed your insight at the meeting mic Randy ... From randy at psg.com Sat May 16 20:11:23 2015 From: randy at psg.com (Randy Bush) Date: Sat, 16 May 2015 08:11:23 -1000 Subject: [address-policy-wg] 2014-03 Review Period extended until 19 May 2015 (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <2E624229-0EFA-4AE4-97D4-020390B83D13@a2b-internet.com> References: <20150515123401.GA15231@Space.Net> <07B9D88D-23CB-45CC-8795-BFC2093F461B@a2b-internet.com> <55571B47.8070701@opteamax.de> <194305A1-1A25-4C75-9F11-45843CB938F9@a2b-internet.com> <2E624229-0EFA-4AE4-97D4-020390B83D13@a2b-internet.com> Message-ID: > We missed your insight at the meeting mic Randy ... i really missed being there we can blame serge, who shifted the meeting left one week from it's traditional time, and thus conflicted with our tenth wedding anniversary :) randy From randy at psg.com Sun May 17 22:18:13 2015 From: randy at psg.com (Randy Bush) Date: Sun, 17 May 2015 10:18:13 -1000 Subject: [address-policy-wg] RE: 2014-03 Review Period extended until 19 May 2015 (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <862A73D42343AE49B2FC3C32FDDFE91C01525504C9@E2010-MBX04.exchange2010.nl> References: <862A73D42343AE49B2FC3C32FDDFE91C01525504C9@E2010-MBX04.exchange2010.nl> Message-ID: >> we can blame serge, who shifted the meeting left one week from it's >> traditional time, and thus conflicted with our tenth wedding anniversary :) > You can't blame Serge for your poor planning in a wedding date ... You > knew 10 years ago that there is a RIPE meeting in may ;) and it has always been the previous week. so we would go to the meeting and then spend the following week ... From erik at bais.name Sun May 17 22:07:39 2015 From: erik at bais.name (Erik Bais) Date: Sun, 17 May 2015 20:07:39 +0000 Subject: [address-policy-wg] RE: 2014-03 Review Period extended until 19 May 2015 (Remove Multihoming Requirement for AS Number Assignments) Message-ID: <862A73D42343AE49B2FC3C32FDDFE91C01525504C9@E2010-MBX04.exchange2010.nl> Hi Randy, > i really missed being there > we can blame serge, who shifted the meeting left one week from it's > traditional time, and thus conflicted with our tenth wedding anniversary :) You can't blame Serge for your poor planning in a wedding date ... You knew 10 years ago that there is a RIPE meeting in may ;) Congratz btw ;-) Erik From danny at danysek.cz Mon May 18 17:28:01 2015 From: danny at danysek.cz (Daniel Suchy) Date: Mon, 18 May 2015 17:28:01 +0200 Subject: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: References: Message-ID: <555A0501.6010307@danysek.cz> Hello, I support this proposal. Regards, Daniel On 11.5.2015 13:43, Marco Schmidt wrote: > Dear colleagues, > > > The draft document for the proposal described in 2015-01, "Alignment of Transfer > Requirements for IPv4 Allocations" has been published. > > The impact analysis that was conducted for this proposal has also been published. > > You can find the full proposal and the impact analysis at: > > https://www.ripe.net/participate/policies/proposals/2015-01 > > and the draft document at: > > https://www.ripe.net/participate/policies/proposals/2015-01/draft > > We encourage you to review this proposal and send your comments to > address-policy-wg at ripe.net before 9 June 2015. > > > Regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC > From David.Huberman at microsoft.com Tue May 19 18:32:42 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Tue, 19 May 2015 16:32:42 +0000 Subject: [address-policy-wg] 2014-03 Review Period extended until 19 May 2015 (Remove Multihoming Requirement for AS Number Assignments) Message-ID: Some data from the ARIN region, courtesy of Richard Jimmerson of ARIN: For the last several years ARIN has been registering AS numbers by issuing the lowest AS number we have in inventory to approved organizations. We ask those organizations if they would be willing to accept an AS number higher in the number range, and outside of the range that previously made up the 2-byte only AS number space. In 2014 we found that nearly 27% of the organizations approved for an AS number elected to receive a 4-byte AS number rather than take the lowest AS number in our inventory. Several organizations unwilling to receive a 4-byte AS number have indicated to ARIN that their transit providers strongly state a preference that their customers use AS numbers from the traditional 2-byte AS number range. More recently, because of a lack of 2-byte AS numbers in the ARIN inventory, the AS number assignments we make are 4-byte AS numbers and outside of the range that previously made up the 2-byte only AS number space. For those organizations who come back to ARIN specifically stating a preference for a 2-byte AS number, we may be able to continue satisfying their requests using AS numbers that have recently been added to the ARIN AS number inventory through returns or revocations. Very recently ARIN received a new assignment of AS numbers from the IANA. Roughly 90 of those were from the 2-byte range. In 2014 there were 12 organizations that elected to receive a 4-byte AS number and later came back to ARIN to exchange it for a 2-byte AS number. Each of these organizations stated issues with their transit providers either unwilling or unable to accept the use of a 4-byte AS number by a customer. 2014 total AS numbers issued: 1,579 2014 4-byte AS numbers issued: 416 2014 2-byte AS numbers issued: 1,163 David R Huberman Principal, Global IP Addressing Microsoft Corporation From frettled at gmail.com Tue May 19 18:55:54 2015 From: frettled at gmail.com (Jan Ingvoldstad) Date: Tue, 19 May 2015 18:55:54 +0200 Subject: [address-policy-wg] 2014-03 Review Period extended until 19 May 2015 (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: References: Message-ID: On Tue, May 19, 2015 at 6:32 PM, David Huberman < David.Huberman at microsoft.com> wrote: > > > In 2014 there were 12 organizations that elected to receive a 4-byte AS > number and later came back to ARIN to exchange it for a 2-byte AS number. > Each of these organizations stated issues with their transit providers > either unwilling or unable to accept the use of a 4-byte AS number by a > customer. > > It's seems as if the transit providers are mentioned a bit too frequently here. Does anyone have any information about how long it would take to get transit providers 4-byte-ready? -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From apwg at c4inet.net Tue May 19 19:13:48 2015 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Tue, 19 May 2015 18:13:48 +0100 Subject: [address-policy-wg] 2014-03 Review Period extended until 19 May 2015 (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: References: Message-ID: <20150519171348.GW35191@cilantro.c4inet.net> On Tue, May 19, 2015 at 06:55:54PM +0200, Jan Ingvoldstad wrote: >It's seems as if the transit providers are mentioned a bit too frequently >here. > >Does anyone have any information about how long it would take to get >transit providers 4-byte-ready? AFAIK, it's not so much a problem with the providers but with vendor support for 4-byte communities. rgds, Sascha Luck From gert at space.net Tue May 19 20:45:27 2015 From: gert at space.net (Gert Doering) Date: Tue, 19 May 2015 20:45:27 +0200 Subject: [address-policy-wg] 2014-03 Review Period extended until 19 May 2015 (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: References: Message-ID: <20150519184527.GN54385@Space.Net> Hi, On Tue, May 19, 2015 at 04:32:42PM +0000, David Huberman wrote: > Each of these organizations stated issues with their transit providers > either unwilling or unable to accept the use of a 4-byte AS number by > a customer. I can see that transit providers might not be able to use 4-byte AS for their own network (because communities in : notation just do not work then), but transit providers refusing customers with 4-byte ASNs in, what, 2014, is so totally lame... Thanks, David, for the update, though! Gert Doering -- proud holder of AS3.3 (AS196611 nowadays, far less pretty) -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From nick at inex.ie Wed May 20 13:56:32 2015 From: nick at inex.ie (Nick Hilliard) Date: Wed, 20 May 2015 12:56:32 +0100 Subject: [address-policy-wg] 2014-03 Review Period extended until 19 May 2015 (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: References: <20150515123401.GA15231@Space.Net> <555683DD.3010605@inex.ie> Message-ID: <555C7670.7050205@inex.ie> On 16/05/2015 03:33, David Huberman wrote: > If the RIRs don't do anything to preserve 2-byte AS numbers, then things > are going to start really breaking. s/RIRs don't do anything to preserve/vendors don't to anything to support/ ASN16 runout is inevitable and is now within sight: IANA's stock is gone. The RIRs can twiddle policy this way or that, but they can't stop runout and will find it difficult even to slow it down. If the vendors are pretending otherwise - either to themselves or their customers - then they are deluded. If RIR run-out hits before they have implemented asn32 support and shaken out all the bugs, then they will find that their kit is obsolete for new customers and this will have commercial implications for them. Nick From David.Huberman at microsoft.com Wed May 20 19:15:11 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Wed, 20 May 2015 17:15:11 +0000 Subject: [address-policy-wg] 2014-03 Review Period extended until 19 May 2015 (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <20150519184527.GN54385@Space.Net> References: <20150519184527.GN54385@Space.Net> Message-ID: Per ARIN's statistics, there were 416 4-byte ASNs issued in CY2014. 12 were returned to ARIN as non-useable. That means that here, on May 20 2015, we should see most of the 404 4-byte ASNs registered in some copy of the DFZ. So let's see! Methodology: - I downloaded 'delegated-arin-extended-latest', today's extended file - I found exactly 421 4-byte ASNs with a registration date in 2014. - I hopped on a Microsoft router and did: show route advertising-protocol bgp [our IP address] aspath-regex ".*(65536-4294967295).*" Interestingly, we found 39,293 prefixes announced or transiting 4-byte ASNs. That's a lot more than expected. - I then looked for all 421 registered 4-byte ASNs from CY2014 in the routing table. Results: 289 4-byte ASNs were found in my company's copy of the DFZ (69%) 132 4-byte ASNs were NOT found (31%) David R Huberman Principal, Global IP Addressing Microsoft Corporation > -----Original Message----- > From: Gert Doering [mailto:gert at space.net] > Sent: Tuesday, May 19, 2015 11:45 AM > To: David Huberman > Cc: address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] 2014-03 Review Period extended until 19 > May 2015 (Remove Multihoming Requirement for AS Number Assignments) > > Hi, > > On Tue, May 19, 2015 at 04:32:42PM +0000, David Huberman wrote: > > Each of these organizations stated issues with their transit providers > > either unwilling or unable to accept the use of a 4-byte AS number by > > a customer. > > I can see that transit providers might not be able to use 4-byte AS for their > own network (because communities in : notation just do not > work then), but transit providers refusing customers with 4-byte ASNs in, > what, 2014, is so totally lame... > > Thanks, David, for the update, though! > > Gert Doering > -- proud holder of AS3.3 (AS196611 nowadays, far less pretty) > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From jprins at betterbe.com Thu May 21 11:43:01 2015 From: jprins at betterbe.com (jan hugo prins) Date: Thu, 21 May 2015 11:43:01 +0200 Subject: [address-policy-wg] New on RIPE Labs: IPv4 Transfers in the RIPE NCC Service Region In-Reply-To: References: <554A25E4.7060108@ripe.net> <895536294.20150507210413@infinitytelecom.ro> <20150508115414.GA23553@danton.fire-world.de> Message-ID: <555DA8A5.1070600@betterbe.com> +1 On 05/08/2015 03:40 PM, remco van mook wrote: > Three years and one day ago, I wrote on this very list: > > "...Personally I'm rather sick and tired of hearing people say 'yes, > let's break IPv4 so we all MUST move to IPv6'. If you think this is > good policy or even good engineering, please think again. It will make > us end up with a broken internet that, surprise, we won't be managing > any more. Breaking IPv4 might lead to increased IPv6 adoption, but not > on the internet as we know it today. Everybody who wants to connect > his organisation to the internet is going to need at least some IPv4 > address space for the time being, so why screw it up for new entrants?..." > > Whether this is about reinventing final /8 or about people making > money on IPv4 transfers does not make one jot of a difference. > > > Remco > > (no hats) > > > > On Fri, May 8, 2015 at 1:54 PM Sebastian Wiesinger > > wrote: > > * Dan L?dtke > [2015-05-08 > 11:33]: > > See, we can not win this games. Let?s stop wasting energy and > > resources on dealing with legacy IP and how to make it work for a > > bit longer. New entrants are entering are market that is not fair, > > and we can not make a real difference. The only way forward is to > > push IPv6 and restore a healthy climate regarding the availability > > of IP addresses. > > Dan, > > if you don't want to invest your time trying to make this market more > fair by all means go ahead and do something else. There are still > people here who would like to try so that new players can enter a > market that will be dominated by IPv4 for some time to come. > > Most people here are pushing IPv6 but as much as you want to bury IPv4 > it will still be around for some time. > > Regards > > Sebastian > > -- > GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 > B9CE) > 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS > NOTICE THE SCYTHE. > -- Terry Pratchett, The Fifth Elephant > -- Met vriendelijke groet / Best regards, Jan Hugo Prins Infra and Isilon storage consultant Auke Vleerstraat 140 E | 7547 AN Enschede | COC 08097527 T +31 (0) 53 48 00 694 | M +31 (0)6 26 358 951 jprins at betterbe.com | www.betterbe.com This e-mail is intended exclusively for the addressee(s), and may not be passed on to, or made available for use by any person other than the addressee(s). Better.be B.V. rules out any and every liability resulting from any electronic transmission. -------------- next part -------------- An HTML attachment was scrubbed... URL: From John.Collins at BIT.admin.ch Fri May 22 11:45:52 2015 From: John.Collins at BIT.admin.ch (John.Collins at BIT.admin.ch) Date: Fri, 22 May 2015 09:45:52 +0000 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) Message-ID: <5D23C81DA72B5A4CACB3B12075F7B347D7E4F54C@SB00112A.adb.intra.admin.ch> Dear Colleagues, On Tue Apr 28 Marco Schmidt wrote: ------------------------------------------------- > > A proposed change to the RIPE Document "IPv6 Address Allocation and Assignment Policy" now is open for discussion. > > The proposal aims to expand the criteria for evaluating initial IPv6 allocations larger than a /29. The RIPE NCC would consider additional aspects beyond only the number of existing users and extent of the organisation's infrastructure. > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2015-03 > I supported this proposal is a previous post and I still do. However as Marco said in his original message above "additional aspects beyond only the number of existing users and extent of the organisation's infrastructure" would be considered by the RIPE-NCC. I want to make a suggestion for such "additional aspects". It might make sense that some inclusive evaluation criteria are listed in the policy. This would make the evaluation task of the RIPE-NCC easier and would also simplify allocation requests from LIRs. I suggest that the following text replaces the existing text in the policy in section 5.1.2 (Initial allocation size) -------------------- begin ------------------------------------------ "Organisations that meet the initial allocation criteria are eligible to receive an initial allocation of /32. For allocations up to /29 no additional documentation is necessary. Organisations may qualify for an initial allocation greater than /29 by submitting documentation that reasonably justifies the request. If so, the allocation size will be based on the number of users, the extent of the organisation's infrastructure, the hierarchical and geographical structuring of the organisation, the segmentation of infrastructure for security and the planned longevity of allocation." -------------------- end -------------------------------------------- Here are some remarks concerning the "additional aspects" (inclusive/positive criteria in the suggested text): number of users, the extent of the organisation's infrastructure ---------------------------------------------------------------------------------- This is like the status quo. It allows the RIPE-NCC to consider the number of existing and future (note the removal of the word "existing" in the suggested policy text) users and the organisation's infrastructure when evaluating address plans. It seems logical that these criteria are included in the evaluation of requests as there is a relationship between the number users and infrastructure and the needed addresses. The more users and the bigger the infrastructure, the more address are needed. hierarchical and geographic structuring ---------------------------------------------------- Allows the RIPE-NCC to consider requirements of (national or multi-national) commercial organisations, governments and military organisations like the UK-MOD concerning the reflection of hierarchy and geographical coverage in the address plan. Even autonomous (sub)organisations are catered for by the 'hierarchy' aspects. the segmentation of infrastructure for security ------------------------------------------------------------ Allows the RIPE-NCC to consider address plans which cater for the separation of infrastructures for security reasons which might include data protection, network and system protection and business continuity assurance for disaster recovery. planned longevity of allocation ---------------------------------------- Allows the RIPE-NCC to take future planning of organisations into account when they reserve enough address space for many years in an effort to avoid renumbering and (at the end of the day) to avoid undue de-aggregation. I do not propose that a specific number of years is mentioned as the interpretation of longevity for one organisation will differ from that of another organisation. As RIPE-NCC's Andrea Cima pointed out at RIPE70, some LIRs plan in terms of 20 years, others in terms of 10 years etc. Finally, I would like to call on the many "Enterprise LIRs" out there to consider this suggestion and if it makes sense to support it on the mailing-list. Also I ask the many "ISP LIRs" to lend their consideration and support. Your feedback is important. The success of IPv6 depends on both LIR categories gaining access to sufficient address space. And thank you very much for reading this far! Best Regards, John From Mathew.Newton643 at official.mod.uk Fri May 22 14:05:43 2015 From: Mathew.Newton643 at official.mod.uk (Mathew Newton) Date: Fri, 22 May 2015 12:05:43 +0000 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: <5D23C81DA72B5A4CACB3B12075F7B347D7E4F54C@SB00112A.adb.intra.admin.ch> References: <5D23C81DA72B5A4CACB3B12075F7B347D7E4F54C@SB00112A.adb.intra.admin.ch> Message-ID: > -----Original Message----- > From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of John.Collins at BIT.admin.ch > Sent: 22 May 2015 10:46 > Organisations may qualify for an initial allocation greater than /29 by > submitting documentation that reasonably justifies the request. If so, the > allocation size will be based on the number of users, the extent of the > organisation's infrastructure, the hierarchical and geographical structuring of > the organisation, the segmentation of infrastructure for security and the > planned longevity of allocation." I fully support the addition of this assessment criteria to the proposal. > Finally, I would like to call on the many "Enterprise LIRs" out there to consider > this suggestion and if it makes sense to support it on the mailing-list. Wholeheartedly agree. If the policy is to satisfy the justified needs of a greater proportion of community then a greater a proportion of the community needs to be involved with its development. And yes, we (UK MOD) are as guilty as anyone for not having done this for far too long in my personal opinion. Regards, Mathew From LIR at bva.bund.de Tue May 26 09:45:54 2015 From: LIR at bva.bund.de (LIR (BIT I 5)) Date: Tue, 26 May 2015 07:45:54 +0000 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: <5D23C81DA72B5A4CACB3B12075F7B347D7E4F54C@SB00112A.adb.intra.admin.ch> References: <5D23C81DA72B5A4CACB3B12075F7B347D7E4F54C@SB00112A.adb.intra.admin.ch> Message-ID: Hello at all, I support the suggestion from John. Regards, Carsten -----Urspr?ngliche Nachricht----- Von: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] Im Auftrag von John.Collins at BIT.admin.ch Gesendet: Freitag, 22. Mai 2015 11:46 An: address-policy-wg at ripe.net Cc: mschmidt at ripe.net Betreff: Re: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) Dear Colleagues, On Tue Apr 28 Marco Schmidt wrote: ------------------------------------------------- > > A proposed change to the RIPE Document "IPv6 Address Allocation and Assignment Policy" now is open for discussion. > > The proposal aims to expand the criteria for evaluating initial IPv6 allocations larger than a /29. The RIPE NCC would consider additional aspects beyond only the number of existing users and extent of the organisation's infrastructure. > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2015-03 > I supported this proposal is a previous post and I still do. However as Marco said in his original message above "additional aspects beyond only the number of existing users and extent of the organisation's infrastructure" would be considered by the RIPE-NCC. I want to make a suggestion for such "additional aspects". It might make sense that some inclusive evaluation criteria are listed in the policy. This would make the evaluation task of the RIPE-NCC easier and would also simplify allocation requests from LIRs. I suggest that the following text replaces the existing text in the policy in section 5.1.2 (Initial allocation size) -------------------- begin ------------------------------------------ "Organisations that meet the initial allocation criteria are eligible to receive an initial allocation of /32. For allocations up to /29 no additional documentation is necessary. Organisations may qualify for an initial allocation greater than /29 by submitting documentation that reasonably justifies the request. If so, the allocation size will be based on the number of users, the extent of the organisation's infrastructure, the hierarchical and geographical structuring of the organisation, the segmentation of infrastructure for security and the planned longevity of allocation." -------------------- end -------------------------------------------- Here are some remarks concerning the "additional aspects" (inclusive/positive criteria in the suggested text): number of users, the extent of the organisation's infrastructure ---------------------------------------------------------------------------------- This is like the status quo. It allows the RIPE-NCC to consider the number of existing and future (note the removal of the word "existing" in the suggested policy text) users and the organisation's infrastructure when evaluating address plans. It seems logical that these criteria are included in the evaluation of requests as there is a relationship between the number users and infrastructure and the needed addresses. The more users and the bigger the infrastructure, the more address are needed. hierarchical and geographic structuring ---------------------------------------------------- Allows the RIPE-NCC to consider requirements of (national or multi-national) commercial organisations, governments and military organisations like the UK-MOD concerning the reflection of hierarchy and geographical coverage in the address plan. Even autonomous (sub)organisations are catered for by the 'hierarchy' aspects. the segmentation of infrastructure for security ------------------------------------------------------------ Allows the RIPE-NCC to consider address plans which cater for the separation of infrastructures for security reasons which might include data protection, network and system protection and business continuity assurance for disaster recovery. planned longevity of allocation ---------------------------------------- Allows the RIPE-NCC to take future planning of organisations into account when they reserve enough address space for many years in an effort to avoid renumbering and (at the end of the day) to avoid undue de-aggregation. I do not propose that a specific number of years is mentioned as the interpretation of longevity for one organisation will differ from that of another organisation. As RIPE-NCC's Andrea Cima pointed out at RIPE70, some LIRs plan in terms of 20 years, others in terms of 10 years etc. Finally, I would like to call on the many "Enterprise LIRs" out there to consider this suggestion and if it makes sense to support it on the mailing-list. Also I ask the many "ISP LIRs" to lend their consideration and support. Your feedback is important. The success of IPv6 depends on both LIR categories gaining access to sufficient address space. And thank you very much for reading this far! Best Regards, John From silvia.hagen at sunny.ch Tue May 26 10:39:55 2015 From: silvia.hagen at sunny.ch (Silvia Hagen) Date: Tue, 26 May 2015 08:39:55 +0000 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: <5D23C81DA72B5A4CACB3B12075F7B347D7E4F54C@SB00112A.adb.intra.admin.ch> References: <5D23C81DA72B5A4CACB3B12075F7B347D7E4F54C@SB00112A.adb.intra.admin.ch> Message-ID: +1 I support this proposal with John Collin's suggestions Silvia Hagen Swiss IPv6 Council -----Urspr?ngliche Nachricht----- Von: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] Im Auftrag von John.Collins at BIT.admin.ch Gesendet: Freitag, 22. Mai 2015 11:46 An: address-policy-wg at ripe.net Cc: mschmidt at ripe.net Betreff: Re: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) Dear Colleagues, On Tue Apr 28 Marco Schmidt wrote: ------------------------------------------------- > > A proposed change to the RIPE Document "IPv6 Address Allocation and Assignment Policy" now is open for discussion. > > The proposal aims to expand the criteria for evaluating initial IPv6 allocations larger than a /29. The RIPE NCC would consider additional aspects beyond only the number of existing users and extent of the organisation's infrastructure. > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2015-03 > I supported this proposal is a previous post and I still do. However as Marco said in his original message above "additional aspects beyond only the number of existing users and extent of the organisation's infrastructure" would be considered by the RIPE-NCC. I want to make a suggestion for such "additional aspects". It might make sense that some inclusive evaluation criteria are listed in the policy. This would make the evaluation task of the RIPE-NCC easier and would also simplify allocation requests from LIRs. I suggest that the following text replaces the existing text in the policy in section 5.1.2 (Initial allocation size) -------------------- begin ------------------------------------------ "Organisations that meet the initial allocation criteria are eligible to receive an initial allocation of /32. For allocations up to /29 no additional documentation is necessary. Organisations may qualify for an initial allocation greater than /29 by submitting documentation that reasonably justifies the request. If so, the allocation size will be based on the number of users, the extent of the organisation's infrastructure, the hierarchical and geographical structuring of the organisation, the segmentation of infrastructure for security and the planned longevity of allocation." -------------------- end -------------------------------------------- Here are some remarks concerning the "additional aspects" (inclusive/positive criteria in the suggested text): number of users, the extent of the organisation's infrastructure ---------------------------------------------------------------------------------- This is like the status quo. It allows the RIPE-NCC to consider the number of existing and future (note the removal of the word "existing" in the suggested policy text) users and the organisation's infrastructure when evaluating address plans. It seems logical that these criteria are included in the evaluation of requests as there is a relationship between the number users and infrastructure and the needed addresses. The more users and the bigger the infrastructure, the more address are needed. hierarchical and geographic structuring ---------------------------------------------------- Allows the RIPE-NCC to consider requirements of (national or multi-national) commercial organisations, governments and military organisations like the UK-MOD concerning the reflection of hierarchy and geographical coverage in the address plan. Even autonomous (sub)organisations are catered for by the 'hierarchy' aspects. the segmentation of infrastructure for security ------------------------------------------------------------ Allows the RIPE-NCC to consider address plans which cater for the separation of infrastructures for security reasons which might include data protection, network and system protection and business continuity assurance for disaster recovery. planned longevity of allocation ---------------------------------------- Allows the RIPE-NCC to take future planning of organisations into account when they reserve enough address space for many years in an effort to avoid renumbering and (at the end of the day) to avoid undue de-aggregation. I do not propose that a specific number of years is mentioned as the interpretation of longevity for one organisation will differ from that of another organisation. As RIPE-NCC's Andrea Cima pointed out at RIPE70, some LIRs plan in terms of 20 years, others in terms of 10 years etc. Finally, I would like to call on the many "Enterprise LIRs" out there to consider this suggestion and if it makes sense to support it on the mailing-list. Also I ask the many "ISP LIRs" to lend their consideration and support. Your feedback is important. The success of IPv6 depends on both LIR categories gaining access to sufficient address space. And thank you very much for reading this far! Best Regards, John From carlosf.gomez at seap.minhap.es Tue May 26 11:01:56 2015 From: carlosf.gomez at seap.minhap.es (=?windows-1252?Q?Carlos_G=F3mez_Mu=F1oz?=) Date: Tue, 26 May 2015 11:01:56 +0200 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: <5D23C81DA72B5A4CACB3B12075F7B347D7E4F54C@SB00112A.adb.intra.admin.ch> References: <5D23C81DA72B5A4CACB3B12075F7B347D7E4F54C@SB00112A.adb.intra.admin.ch> Message-ID: <55643684.8000006@seap.minhap.es> I support the proposal with the addition suggested by John. Best regards, Carlos G?mez es.seap Spanish government LIR El 22/05/2015 a las 11:45, John.Collins at BIT.admin.ch escribi?: > Dear Colleagues, > > On Tue Apr 28 Marco Schmidt wrote: > ------------------------------------------------- > >> A proposed change to the RIPE Document "IPv6 Address Allocation and Assignment Policy" now is open for discussion. >> >> The proposal aims to expand the criteria for evaluating initial IPv6 allocations larger than a /29. The RIPE NCC would consider additional aspects beyond only the number of existing users and extent of the organisation's infrastructure. >> >> You can find the full proposal at: >> >> https://www.ripe.net/participate/policies/proposals/2015-03 >> > > I supported this proposal is a previous post and I still do. However as Marco said in his original message above "additional aspects beyond only the number of existing users and extent of the organisation's infrastructure" would be considered by the RIPE-NCC. I want to make a suggestion for such "additional aspects". It might make sense that some inclusive evaluation criteria are listed in the policy. This would make the evaluation task of the RIPE-NCC easier and would also simplify allocation requests from LIRs. > > I suggest that the following text replaces the existing text in the policy in section 5.1.2 (Initial allocation size) > > -------------------- begin ------------------------------------------ > "Organisations that meet the initial allocation criteria are eligible to receive an initial allocation of /32. For allocations up to /29 no additional documentation is necessary. > > Organisations may qualify for an initial allocation greater than /29 by submitting documentation that reasonably justifies the request. If so, the allocation size will be based on the number of users, the extent of the organisation's infrastructure, the hierarchical and geographical structuring of the organisation, the segmentation of infrastructure for security and the planned longevity of allocation." > -------------------- end -------------------------------------------- > > > Here are some remarks concerning the "additional aspects" (inclusive/positive criteria in the suggested text): > > number of users, the extent of the organisation's infrastructure > ---------------------------------------------------------------------------------- > This is like the status quo. It allows the RIPE-NCC to consider the number of existing and future (note the removal of the word "existing" in the suggested policy text) users and the organisation's infrastructure when evaluating address plans. It seems logical that these criteria are included in the evaluation of requests as there is a relationship between the number users and infrastructure and the needed addresses. The more users and the bigger the infrastructure, the more address are needed. > > hierarchical and geographic structuring > ---------------------------------------------------- > Allows the RIPE-NCC to consider requirements of (national or multi-national) commercial organisations, governments and military organisations like the UK-MOD concerning the reflection of hierarchy and geographical coverage in the address plan. Even autonomous (sub)organisations are catered for by the 'hierarchy' aspects. > > the segmentation of infrastructure for security > ------------------------------------------------------------ > Allows the RIPE-NCC to consider address plans which cater for the separation of infrastructures for security reasons which might include data protection, network and system protection and business continuity assurance for disaster recovery. > > planned longevity of allocation > ---------------------------------------- > Allows the RIPE-NCC to take future planning of organisations into account when they reserve enough address space for many years in an effort to avoid renumbering and (at the end of the day) to avoid undue de-aggregation. I do not propose that a specific number of years is mentioned as the interpretation of longevity for one organisation will differ from that of another organisation. As RIPE-NCC's Andrea Cima pointed out at RIPE70, some LIRs plan in terms of 20 years, others in terms of 10 years etc. > > > Finally, I would like to call on the many "Enterprise LIRs" out there to consider this suggestion and if it makes sense to support it on the mailing-list. Also I ask the many "ISP LIRs" to lend their consideration and support. Your feedback is important. The success of IPv6 depends on both LIR categories gaining access to sufficient address space. > > And thank you very much for reading this far! > > Best Regards, > John > > > From alexander.brinkmann at kaufland.com Tue May 26 11:37:09 2015 From: alexander.brinkmann at kaufland.com (alexander.brinkmann at kaufland.com) Date: Tue, 26 May 2015 11:37:09 +0200 Subject: [address-policy-wg] WG: Re: 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) Message-ID: Hi all, I support this proposal, too, Thanks John Mit freundlichen Gr??en / Best Regards Alexander Brinkmann Tel.: +49 7132 949665 Fax: +49 7132 9479665 EMail: alexander.brinkmann at kaufland.com KI 967850 IT International / IT Governance / Netzwerk Design und IT-Sicherheit Office: Haller Stra?e 60 74189 Weinsberg http://www.kaufland.de http://www.spannende-it.de Kaufland Informationssysteme GmbH & Co. KG Postfach 12 53 - 74149 Neckarsulm Kommanditgesellschaft Sitz: Neckarsulm Registergericht: Stuttgart HRA 104163 ----- Weitergeleitet von Alexander Brinkmann/IS/KI/KAUFLAND am 26.05.2015 11:36 ----- Von: Carlos G?mez Mu?oz An: John.Collins at BIT.admin.ch, address-policy-wg at ripe.net Kopie: mschmidt at ripe.net Datum: 26.05.2015 11:03 Betreff: Re: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) Gesendet von: "address-policy-wg" I support the proposal with the addition suggested by John. Best regards, Carlos G?mez es.seap Spanish government LIR El 22/05/2015 a las 11:45, John.Collins at BIT.admin.ch escribi?: > Dear Colleagues, > > On Tue Apr 28 Marco Schmidt wrote: > ------------------------------------------------- > >> A proposed change to the RIPE Document "IPv6 Address Allocation and Assignment Policy" now is open for discussion. >> >> The proposal aims to expand the criteria for evaluating initial IPv6 allocations larger than a /29. The RIPE NCC would consider additional aspects beyond only the number of existing users and extent of the organisation's infrastructure. >> >> You can find the full proposal at: >> >> https://www.ripe.net/participate/policies/proposals/2015-03 >> > > I supported this proposal is a previous post and I still do. However as Marco said in his original message above "additional aspects beyond only the number of existing users and extent of the organisation's infrastructure" would be considered by the RIPE-NCC. I want to make a suggestion for such "additional aspects". It might make sense that some inclusive evaluation criteria are listed in the policy. This would make the evaluation task of the RIPE-NCC easier and would also simplify allocation requests from LIRs. > > I suggest that the following text replaces the existing text in the policy in section 5.1.2 (Initial allocation size) > > -------------------- begin ------------------------------------------ > "Organisations that meet the initial allocation criteria are eligible to receive an initial allocation of /32. For allocations up to /29 no additional documentation is necessary. > > Organisations may qualify for an initial allocation greater than /29 by submitting documentation that reasonably justifies the request. If so, the allocation size will be based on the number of users, the extent of the organisation's infrastructure, the hierarchical and geographical structuring of the organisation, the segmentation of infrastructure for security and the planned longevity of allocation." > -------------------- end -------------------------------------------- > > > Here are some remarks concerning the "additional aspects" (inclusive/positive criteria in the suggested text): > > number of users, the extent of the organisation's infrastructure > ---------------------------------------------------------------------------------- > This is like the status quo. It allows the RIPE-NCC to consider the number of existing and future (note the removal of the word "existing" in the suggested policy text) users and the organisation's infrastructure when evaluating address plans. It seems logical that these criteria are included in the evaluation of requests as there is a relationship between the number users and infrastructure and the needed addresses. The more users and the bigger the infrastructure, the more address are needed. > > hierarchical and geographic structuring > ---------------------------------------------------- > Allows the RIPE-NCC to consider requirements of (national or multi-national) commercial organisations, governments and military organisations like the UK-MOD concerning the reflection of hierarchy and geographical coverage in the address plan. Even autonomous (sub)organisations are catered for by the 'hierarchy' aspects. > > the segmentation of infrastructure for security > ------------------------------------------------------------ > Allows the RIPE-NCC to consider address plans which cater for the separation of infrastructures for security reasons which might include data protection, network and system protection and business continuity assurance for disaster recovery. > > planned longevity of allocation > ---------------------------------------- > Allows the RIPE-NCC to take future planning of organisations into account when they reserve enough address space for many years in an effort to avoid renumbering and (at the end of the day) to avoid undue de-aggregation. I do not propose that a specific number of years is mentioned as the interpretation of longevity for one organisation will differ from that of another organisation. As RIPE-NCC's Andrea Cima pointed out at RIPE70, some LIRs plan in terms of 20 years, others in terms of 10 years etc. > > > Finally, I would like to call on the many "Enterprise LIRs" out there to consider this suggestion and if it makes sense to support it on the mailing-list. Also I ask the many "ISP LIRs" to lend their consideration and support. Your feedback is important. The success of IPv6 depends on both LIR categories gaining access to sufficient address space. > > And thank you very much for reading this far! > > Best Regards, > John > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 12117024.gif Type: image/gif Size: 20176 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 12239758.gif Type: image/gif Size: 1090 bytes Desc: not available URL: From Thomas01.Schmidt at conti.de Wed May 27 16:22:14 2015 From: Thomas01.Schmidt at conti.de (Thomas01.Schmidt at conti.de) Date: Wed, 27 May 2015 16:22:14 +0200 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) Message-ID: Dear Colleagues, On Fri May 22 John Collins wrote: ----------------------------------------- Finally, I would like to call on the many "Enterprise LIRs" out there to consider this suggestion and if it makes sense to support it on the mailing-list. Also I ask the many "ISP LIRs" to lend their consideration and support. Your feedback is important. The success of IPv6 depends on both LIR categories gaining access to sufficient address space. ----------------------------------------- I represent on of these "Enterprise LIRs" and like to support this proposal. The organisational structure could request specific consideration in the IP address management design (e.g. caused by M&A, subsidaries or divisional independencies under a holding). The removed text in the new policy proposal ------------------begin--------------- If so, the allocation size will be based on the number of existing users and the extent of the organisation's infrastructure. -----------------end------------------ gives the freedom to allocated an address design independ by the number of existing users. We currently face the existing limitation by become LIR at ARIN and APNIC too. The additional address allocations helps us to cover the global parts of the company with sufficient address space but with additional expenses and costs. Mit freundlichen Gr??en / Kind regards / Meilleures salutations Thomas Schmidt IT Corporate Infrastructure Strategy, Network IT CO IN ST N Continental AG Vahrenwalder Str. 9, D-30165 Hannover, GERMANY Phone: 0049 511 938-1269 Telefax: 0049 511 938-81269 Email: Thomas01.Schmidt at conti.de http://www.conti.com http://www.continental-corporation.com --------------------------------------------------------------------------- -- Continental Aktiengesellschaft, Postfach/Postbox 1 69, D-30001 Hannover Vorsitzender des Aufsichtsrats/Chairman of the Supervisory Board: Prof. Dr. Ing. Wolfgang Reitzle Vorstand/Executive Board: Dr. Elmar Degenhart (Vorsitzender/Chairman), Jose A. Avila, Dr. Ralf Cramer, Frank Jourdan, Helmut Matschi, Dr. Ariane Reinhart, Wolfgang Schaefer, Nikolai Setzer, Hans-Juergen Duensing Sitz der Gesellschaft/Registered Office: Hannover Registergericht/Registered Court: Amtsgericht Hannover, HRB 3527, USt.-ID-Nr./VAT-ID-No. DE 115645799 --------------------------------------------------------------------------- -- Proprietary and confidential. Distribution only by express authority of Continental AG or its subsidiaries. -------------- next part -------------- An HTML attachment was scrubbed... URL: From erey at ernw.de Wed May 27 20:33:07 2015 From: erey at ernw.de (Enno Rey) Date: Wed, 27 May 2015 20:33:07 +0200 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: References: Message-ID: <20150527183307.GC56542@ernw.de> All, I'd like to strongly support the proposal as well. To be fully honest here I've not yet encountered a single adress planning exercise where "we" (which included organizations with +300K users and 700K IP addresses in their IPAM database) didn't easily get along with a /32. I hence initially shared the scepticism ("Rly? who needs more than a /29?") brought up at the mic and on the mailing list. Still, I found the perspective laid out by Mathew convincing and in general I think RIPE policies (and their assumptions) shouldn't come into the way of organizations with flexible needs based on their individual environments. Overall the criteria provided by John (Collins) can be a reasonable starting point for the development of criteria needed, but they'll probably need some refinement. Best Enno On Wed, May 27, 2015 at 04:22:14PM +0200, Thomas01.Schmidt at conti.de wrote: > Dear Colleagues, > > On Fri May 22 John Collins wrote: > > ----------------------------------------- > > Finally, I would like to call on the many "Enterprise LIRs" out there to > consider this suggestion and if it makes sense to support it on the > mailing-list. Also I ask the many "ISP LIRs" to lend their consideration > and support. Your feedback is important. The success of IPv6 depends on > both LIR categories gaining access to sufficient address space. > > ----------------------------------------- > > I represent on of these "Enterprise LIRs" and like to support this > proposal. The organisational structure could request specific > consideration in the IP address management design (e.g. caused by M&A, > subsidaries or divisional independencies under a holding). The removed > text in the new policy proposal > > ------------------begin--------------- > > If so, the allocation size will be based on the number of existing users > and the extent of the organisation's infrastructure. > > -----------------end------------------ > > gives the freedom to allocated an address design independ by the number of > existing users. > We currently face the existing limitation by become LIR at ARIN and APNIC > too. The additional address allocations helps us to cover the global parts > of the company with sufficient address space but with additional expenses > and costs. > > > Mit freundlichen Gr??en / Kind regards / Meilleures salutations > > Thomas Schmidt > IT Corporate Infrastructure Strategy, Network > IT CO IN ST N > > Continental AG > Vahrenwalder Str. 9, D-30165 Hannover, GERMANY > > Phone: 0049 511 938-1269 > Telefax: 0049 511 938-81269 > Email: Thomas01.Schmidt at conti.de > http://www.conti.com > http://www.continental-corporation.com > --------------------------------------------------------------------------- > -- > Continental Aktiengesellschaft, Postfach/Postbox 1 69, D-30001 Hannover > Vorsitzender des Aufsichtsrats/Chairman of the Supervisory Board: > Prof. Dr. Ing. Wolfgang Reitzle > Vorstand/Executive Board: Dr. Elmar Degenhart (Vorsitzender/Chairman), > Jose A. Avila, Dr. Ralf Cramer, Frank Jourdan, Helmut Matschi, > Dr. Ariane Reinhart, Wolfgang Schaefer, Nikolai Setzer, Hans-Juergen > Duensing > Sitz der Gesellschaft/Registered Office: Hannover > Registergericht/Registered Court: Amtsgericht Hannover, HRB 3527, > USt.-ID-Nr./VAT-ID-No. DE 115645799 > --------------------------------------------------------------------------- > -- > Proprietary and confidential. Distribution only by express > authority of Continental AG or its subsidiaries. -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From apwg at c4inet.net Wed May 27 20:59:13 2015 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Wed, 27 May 2015 19:59:13 +0100 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: <5D23C81DA72B5A4CACB3B12075F7B347D7E4F54C@SB00112A.adb.intra.admin.ch> References: <5D23C81DA72B5A4CACB3B12075F7B347D7E4F54C@SB00112A.adb.intra.admin.ch> Message-ID: <20150527185913.GX35191@cilantro.c4inet.net> On Fri, May 22, 2015 at 09:45:52AM +0000, John.Collins at BIT.admin.ch wrote: >Organisations may qualify for an initial allocation greater than >/29 by submitting documentation that reasonably justifies the >request. If so, the allocation size will be based on the number >of users, the extent of the organisation's infrastructure, the >hierarchical and geographical structuring of the organisation, >the segmentation of infrastructure for security and the planned >longevity of allocation." -------------------- end I support the proposal as-is, without any list of "allowed" parameters, for those reasons: 1) I doubt we can come up with an exhaustive list of parameters for request evaluation and so we will be here again next year when there will be an edge case not catered for. 2) Both the current and the here proposed list are biased towards conservationism, where ripe-641 explicitly states that aggregation is the greater good. rgds, Sascha Luck From John.Collins at BIT.admin.ch Thu May 28 07:21:20 2015 From: John.Collins at BIT.admin.ch (John.Collins at BIT.admin.ch) Date: Thu, 28 May 2015 05:21:20 +0000 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: <20150527185913.GX35191@cilantro.c4inet.net> References: <5D23C81DA72B5A4CACB3B12075F7B347D7E4F54C@SB00112A.adb.intra.admin.ch> <20150527185913.GX35191@cilantro.c4inet.net> Message-ID: <5D23C81DA72B5A4CACB3B12075F7B347D7E5035F@SB00112A.adb.intra.admin.ch> Hi Sacha, you wrote: > I support the proposal as-is, without any list of "allowed" > parameters, for those reasons: > > 1) I doubt we can come up with an exhaustive list of parameters for request evaluation and so we will be here again next year when there will be an edge case not catered for. > >2) Both the current and the here proposed list are biased towards conservationism, where ripe-641 explicitly states that aggregation is the greater good. > Thanks for your support. In your previous post on 28 April you voiced the fear that transparency is an issue if the text is removed and asked that this be addressed in the NCC Impact Statement. I hope that the NCC does this. With my suggested criteria I was thinking of the 20 large requests mentioned my Andrea Cima in his presentation at RIPE70 where hierarchy and longevity of allocation could not be considered by the NCC when evaluating requests. Maybe not all "edge cases" are covered, but I hope that a large number of cases will be covered. I think that this is better than the current situation. Concerning the bias towards the conservation of address space I believe that my suggestion relaxes the current constraints to a sensible degree. Without policy anchored judgement criteria, what "reasonably justifies the request" will be difficult to identify opening the door to arbitrariness. Best regards, John From John.Collins at BIT.admin.ch Thu May 28 07:46:53 2015 From: John.Collins at BIT.admin.ch (John.Collins at BIT.admin.ch) Date: Thu, 28 May 2015 05:46:53 +0000 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: <20150527183307.GC56542@ernw.de> References: <20150527183307.GC56542@ernw.de> Message-ID: <5D23C81DA72B5A4CACB3B12075F7B347D7E50389@SB00112A.adb.intra.admin.ch> Hi Enno, many thanks for your message and support. It might be useful to learn what refinement the RIPE community thinks is needed. Best regards, John