From mschmidt at ripe.net Thu Apr 14 14:41:41 2016 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 14 Apr 2016 14:41:41 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) Message-ID: <570F9005.4090008@ripe.net> Dear colleagues, The Discussion Period for the policy proposal 2015-05, "Last /8 Allocation Criteria Revision" has been extended until 13 May 2016. The goal of this proposal is to allow LIRs to request an additional /22 IPv4 allocation from the RIPE NCC every 18 months. The text of the proposal has been revised based on mailing list feedback and we have published a new version (2.0) today. As a result, a new Discussion Phase has started for the proposal. Some of the differences from version 1.0 include: - Additional /22 IPv4 allocations can be only provided from address space outside 185/8 - Only LIRs with less than a /20 in total are eligible to receive additional allocations - LIRs must document their IPv6 deployment as part of the request You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2015-05 We encourage you to review this policy proposal and send your comments to . Regards, Marco Schmidt Policy Development Officer RIPE NCC From phessler at theapt.org Thu Apr 14 14:51:15 2016 From: phessler at theapt.org (Peter Hessler) Date: Thu, 14 Apr 2016 14:51:15 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <570F9005.4090008@ripe.net> References: <570F9005.4090008@ripe.net> Message-ID: <20160414125115.GC25856@gir.theapt.org> While I appreciate that there are more restricions on who is eligable to receive new allocations, I am still opposed to this proposal for the simple reason of "it depletes the IPv4 pool faster, and causes problems for new entrants". -- Anybody can win, unless there happens to be a second entry. From aleksbulgakov at gmail.com Thu Apr 14 15:25:27 2016 From: aleksbulgakov at gmail.com (Aleksey Bulgakov) Date: Thu, 14 Apr 2016 16:25:27 +0300 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <20160414125115.GC25856@gir.theapt.org> References: <570F9005.4090008@ripe.net> <20160414125115.GC25856@gir.theapt.org> Message-ID: I think IPv4 exhaustion will lead to IPv6 switching and the problem is solved automatically. And there is no new proposals, discussions and others. While I appreciate that there are more restricions on who is eligable to receive new allocations, I am still opposed to this proposal for the simple reason of "it depletes the IPv4 pool faster, and causes problems for new entrants". -- Anybody can win, unless there happens to be a second entry. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aled.w.morris at googlemail.com Thu Apr 14 16:34:37 2016 From: aled.w.morris at googlemail.com (Aled Morris) Date: Thu, 14 Apr 2016 15:34:37 +0100 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <20160414125115.GC25856@gir.theapt.org> References: <570F9005.4090008@ripe.net> <20160414125115.GC25856@gir.theapt.org> Message-ID: Peter, I agree with the proposal because it makes it possible for recent entrants into the market to grow. Speaking on behalf of such an entity, it's difficult to grow when you're limited to your one /22 in today's market. We (as an industry) are not there with IPv6 for this to be the only option. Ring-fencing 185/8 for new LIRs is sensible, this policy is really about recycling returned addresses and solves a real problem for a lot of recent new entrants. Of course we are all working on introducing IPv6 but I think we need this policy as it complements the allocation from 185/8 for new LIRs with a fair mechanism for nurturing LIRs who have filled their initial allocation. Aled On 14 April 2016 at 13:51, Peter Hessler wrote: > While I appreciate that there are more restricions on who is eligable to > receive new allocations, I am still opposed to this proposal for the > simple reason of "it depletes the IPv4 pool faster, and causes problems > for new entrants". > > > -- > Anybody can win, unless there happens to be a second entry. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at servereasy.it Thu Apr 14 16:48:20 2016 From: info at servereasy.it (Servereasy) Date: Thu, 14 Apr 2016 16:48:20 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <570F9005.4090008@ripe.net> <20160414125115.GC25856@gir.theapt.org> Message-ID: <570FADB4.80509@servereasy.it> As young ISP, I totally agree with Aled. This solves lot of problem for us. Il 14/04/2016 16:34, Aled Morris ha scritto: > Peter, > > I agree with the proposal because it makes it possible for recent > entrants into the market to grow. Speaking on behalf of such an > entity, it's difficult to grow when you're limited to your one /22 in > today's market. We (as an industry) are not there with IPv6 for this > to be the only option. > > Ring-fencing 185/8 for new LIRs is sensible, this policy is really > about recycling returned addresses and solves a real problem for a lot > of recent new entrants. > > Of course we are all working on introducing IPv6 but I think we need > this policy as it complements the allocation from 185/8 for new LIRs > with a fair mechanism for nurturing LIRs who have filled their initial > allocation. > Aled > > On 14 April 2016 at 13:51, Peter Hessler > wrote: > > While I appreciate that there are more restricions on who is > eligable to > receive new allocations, I am still opposed to this proposal for the > simple reason of "it depletes the IPv4 pool faster, and causes > problems > for new entrants". > > > -- > Anybody can win, unless there happens to be a second entry. > > -- Saverio Giuntini Servereasy di Giuntini Saverio Amministrazione e system manager -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe at scholarwebservices.com Thu Apr 14 16:51:56 2016 From: ripe at scholarwebservices.com (ripe at scholarwebservices.com) Date: Thu, 14 Apr 2016 15:51:56 +0100 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <570F9005.4090008@ripe.net> <20160414125115.GC25856@gir.theapt.org> Message-ID: <44515e0cc3a4bab757dbf0bab60999fe@gadago.net> Hello, I am in favour of the proposal. Similar to Aled's comments below, we are a small entity that is restricted to growth with a single /22. I believe the 185/8 should be restricted to new entrants but allowing recycled/returned address space (outside of the 185/8) to be allocated, providing the LIR has less than a /20 in total. Kind regards, Gavin On 2016-04-14 15:34, Aled Morris wrote: > Peter, > > I agree with the proposal because it makes it possible for recent entrants into the market to grow. Speaking on behalf of such an entity, it's difficult to grow when you're limited to your one /22 in today's market. We (as an industry) are not there with IPv6 for this to be the only option. > > Ring-fencing 185/8 for new LIRs is sensible, this policy is really about recycling returned addresses and solves a real problem for a lot of recent new entrants. > > Of course we are all working on introducing IPv6 but I think we need this policy as it complements the allocation from 185/8 for new LIRs with a fair mechanism for nurturing LIRs who have filled their initial allocation. > > Aled > > On 14 April 2016 at 13:51, Peter Hessler wrote: > >> While I appreciate that there are more restricions on who is eligable to >> receive new allocations, I am still opposed to this proposal for the >> simple reason of "it depletes the IPv4 pool faster, and causes problems >> for new entrants". >> >> -- >> Anybody can win, unless there happens to be a second entry. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ian.Dickinson at sky.uk Thu Apr 14 17:01:00 2016 From: Ian.Dickinson at sky.uk (Dickinson, Ian) Date: Thu, 14 Apr 2016 15:01:00 +0000 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <570F9005.4090008@ripe.net> References: <570F9005.4090008@ripe.net> Message-ID: <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> I object to this proposal as written. I do not believe there should be any distinction in policy based on a notional arbitrary "size" of LIR. Ian -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Marco Schmidt Sent: 14 April 2016 13:42 To: address-policy-wg at ripe.net Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) Dear colleagues, The Discussion Period for the policy proposal 2015-05, "Last /8 Allocation Criteria Revision" has been extended until 13 May 2016. The goal of this proposal is to allow LIRs to request an additional /22 IPv4 allocation from the RIPE NCC every 18 months. The text of the proposal has been revised based on mailing list feedback and we have published a new version (2.0) today. As a result, a new Discussion Phase has started for the proposal. Some of the differences from version 1.0 include: - Additional /22 IPv4 allocations can be only provided from address space outside 185/8 - Only LIRs with less than a /20 in total are eligible to receive additional allocations - LIRs must document their IPv6 deployment as part of the request You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2015-05 We encourage you to review this policy proposal and send your comments to . Regards, Marco Schmidt Policy Development Officer RIPE NCC Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD. From dominik at clouvider.co.uk Thu Apr 14 17:02:07 2016 From: dominik at clouvider.co.uk (Dominik Nowacki) Date: Thu, 14 Apr 2016 15:02:07 +0000 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> Message-ID: And why is that Ian ? Dominik -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Dickinson, Ian Sent: 14 April 2016 16:01 To: Marco Schmidt ; address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) I object to this proposal as written. I do not believe there should be any distinction in policy based on a notional arbitrary "size" of LIR. Ian -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Marco Schmidt Sent: 14 April 2016 13:42 To: address-policy-wg at ripe.net Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) Dear colleagues, The Discussion Period for the policy proposal 2015-05, "Last /8 Allocation Criteria Revision" has been extended until 13 May 2016. The goal of this proposal is to allow LIRs to request an additional /22 IPv4 allocation from the RIPE NCC every 18 months. The text of the proposal has been revised based on mailing list feedback and we have published a new version (2.0) today. As a result, a new Discussion Phase has started for the proposal. Some of the differences from version 1.0 include: - Additional /22 IPv4 allocations can be only provided from address space outside 185/8 - Only LIRs with less than a /20 in total are eligible to receive additional allocations - LIRs must document their IPv6 deployment as part of the request You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2015-05 We encourage you to review this policy proposal and send your comments to . Regards, Marco Schmidt Policy Development Officer RIPE NCC Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD. From matei at profisol.ro Thu Apr 14 17:17:28 2016 From: matei at profisol.ro (Storch Matei) Date: Thu, 14 Apr 2016 18:17:28 +0300 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> Message-ID: Hi, All LIRs should be treated equally, regardless of what size they are or how old they are. That is why the current charging scheme taxes all LIRs equally now. If you hold more resources, it doesn't mean you have more money (to purchase from the free market). Just as the last /8 states now, ALL LIRs are allowed to request a one time allocation of a /22. This should be kept in the new proposal as well. So in my opinion, the condition regarding the size of the LIR should be taken out completely. The condition regarding transfering resources out of the LIR is ok, but there should be a limit there as well - for example "in the last two years preceeding the new request", just like transfer is prohibited for two years after they receive resources (transfers or allocations from RIPE). We have to consider the fact that RIPE servers a very large comunity with A LOT of countries that are unstable economically and politically. So if for example, during a crisis (war, hostile takeover of territories, international sanctions, economy falling, etc), a company decides to cut down it's activity to a minimum, they transfer the freed resources. But if in two years the economic/politic situation changes and they've grown since then, they should be able to request additional resources (as per the proposed policy). IPv6 deployment and usage must be a firm criteria for the additional allocation, just like it was in the begining for the /22 request from 185/8 range. Maybe even a more strict documentation of this usage should be enforced (not simply announcing for example, for example a 5 star rating ... Something definite that can show continuos actual usage of IPv6). Regards, Matei Storch Profisol Telecom 0728.555.004 > On 14 apr. 2016, at 18:02, Dominik Nowacki wrote: > > And why is that Ian ? > > Dominik > > -----Original Message----- > From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Dickinson, Ian > Sent: 14 April 2016 16:01 > To: Marco Schmidt ; address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) > > I object to this proposal as written. > > I do not believe there should be any distinction in policy based on a notional arbitrary "size" of LIR. > > Ian > > -----Original Message----- > From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Marco Schmidt > Sent: 14 April 2016 13:42 > To: address-policy-wg at ripe.net > Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) > > Dear colleagues, > > The Discussion Period for the policy proposal 2015-05, "Last /8 Allocation Criteria Revision" has been extended until 13 May 2016. > > The goal of this proposal is to allow LIRs to request an additional /22 > IPv4 allocation from the RIPE NCC every 18 months. > > The text of the proposal has been revised based on mailing list feedback and we have published a new version (2.0) today. As a result, a new Discussion Phase has started for the proposal. > > Some of the differences from version 1.0 include: > - Additional /22 IPv4 allocations can be only provided from address space outside 185/8 > - Only LIRs with less than a /20 in total are eligible to receive additional allocations > - LIRs must document their IPv6 deployment as part of the request > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2015-05 > > We encourage you to review this policy proposal and send your comments to . > > Regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC > > Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD. From Ian.Dickinson at sky.uk Thu Apr 14 17:08:41 2016 From: Ian.Dickinson at sky.uk (Dickinson, Ian) Date: Thu, 14 Apr 2016 15:08:41 +0000 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> Message-ID: <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> "Small" providers want to grow. "Large" providers want to grow too. "Medium" providers presumably want to grow as well. (for some value of "grow") In all cases, this means IPv6, not IPv4. I prefer the current policy that is in place. Ian -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Dominik Nowacki Sent: 14 April 2016 16:02 To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) And why is that Ian ? Dominik -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Dickinson, Ian Sent: 14 April 2016 16:01 To: Marco Schmidt ; address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) I object to this proposal as written. I do not believe there should be any distinction in policy based on a notional arbitrary "size" of LIR. Ian -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Marco Schmidt Sent: 14 April 2016 13:42 To: address-policy-wg at ripe.net Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) Dear colleagues, The Discussion Period for the policy proposal 2015-05, "Last /8 Allocation Criteria Revision" has been extended until 13 May 2016. The goal of this proposal is to allow LIRs to request an additional /22 IPv4 allocation from the RIPE NCC every 18 months. The text of the proposal has been revised based on mailing list feedback and we have published a new version (2.0) today. As a result, a new Discussion Phase has started for the proposal. Some of the differences from version 1.0 include: - Additional /22 IPv4 allocations can be only provided from address space outside 185/8 - Only LIRs with less than a /20 in total are eligible to receive additional allocations - LIRs must document their IPv6 deployment as part of the request You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2015-05 We encourage you to review this policy proposal and send your comments to . Regards, Marco Schmidt Policy Development Officer RIPE NCC Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD. Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD. From jim at rfc1035.com Thu Apr 14 17:36:01 2016 From: jim at rfc1035.com (Jim Reid) Date: Thu, 14 Apr 2016 16:36:01 +0100 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> Message-ID: <6388A1B7-AF9F-4C68-AC64-577269302CC2@rfc1035.com> > On 14 Apr 2016, at 16:08, Dickinson, Ian wrote: > > I prefer the current policy that is in place. +100. Kill 2015-05! Nuke it from orbit, just to be sure. From rhe at nosc.ja.net Thu Apr 14 17:37:18 2016 From: rhe at nosc.ja.net (Rob Evans) Date: Thu, 14 Apr 2016 16:37:18 +0100 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> Message-ID: <20160414153718.GA10236@jobspension.ja.net> Hi, > I do not believe there should be any distinction in policy based > on a notional arbitrary "size" of LIR. I almost agree with you, and it's the difference between a LIR that holds a /21 and one that holds a /20 that's concerning me, but with a feeling that an extra /22 may be of far more use to an LIR that only holds a /22 to one that has, say, /14 of space. The RIPE community has tried to walk a line between keeping IPv4 addresses back to ensure new entrants can join the market, and not needlessly hoarding addresses. The problem with that approach is that we are forever doomed to make small adjustments to the policy to keep that balance. Give or take a bit of fluctuation when the IANA doles out a bit more returned space, the pool of available IPv4 space the NCC has is about the same now as it was three years ago, but we're about half-way through 185/8: https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustion/ipv4-available-pool-graph Interestingly that graph doesn't appear to show much of a change following the "multiple LIR" decision at the last meeting. One /16 out of the final /8 is reserved for some future need, which means that there are ~16,320 /22s in that block. Let's say that's in the same order of magniture as there are RIPE NCC members (12,830 at the end of 2015), but it's not a large breathing gap. The NCC only has about 8,000 /22s outside 185/8 (at the moment), so it all depends on what we want to classify as distributing them fairly. Another /22 for those that need it? How much will that pool continue to grow? Is there a distribution of number of members by address space they hold? I'm also not sure about the "RIPEness" requirement. It's an interesting metric, but why three rather than four? Should we be encoding in policy a requirement that the NCC can change at will? My personal opinion (working on a network that's offered IPv6 in some way shape or form for 19 years), is that how I run my network is my (or perhaps more importantly, my customers') business. Still, at least it gives us something to talk about in Address Policy. Life would be boring otherwise. Cheers, Rob From aled.w.morris at googlemail.com Thu Apr 14 17:59:55 2016 From: aled.w.morris at googlemail.com (Aled Morris) Date: Thu, 14 Apr 2016 16:59:55 +0100 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> Message-ID: Ian, This policy isn't going to change the ability of a large organisation to grown since the amount of space we're talking about is relatively small, and totally trivial to an LIR with (the equivalent of) nearly 700 /22s. I don't think the policy fails the test of "fairness" simply because larger LIRs won't be getting addresses as the "benefit" of an additional /22 would be marginal for them anyway. I would hope that large LIRs don't make objections to this proposal just because they don't see any benefit to them - that come come across as selfish. If we limit the allocation of remaining space to brand new LIRs only, it means that small ISPs in their first growth spurt might be driven to form a second LIR to get that second /22 of space.. I know companies who've done this. It isn't sensible. The proposal makes it possible to achieve the sensible result without resorting to stupid behaviour. Aled On 14 April 2016 at 16:08, Dickinson, Ian wrote: > "Small" providers want to grow. > "Large" providers want to grow too. > "Medium" providers presumably want to grow as well. > (for some value of "grow") > > In all cases, this means IPv6, not IPv4. > > I prefer the current policy that is in place. > > Ian > > -----Original Message----- > From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On > Behalf Of Dominik Nowacki > Sent: 14 April 2016 16:02 > To: address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] 2015-05 Discussion Period extended until > 13 May 2016 (Last /8 Allocation Criteria Revision) > > And why is that Ian ? > > Dominik > > -----Original Message----- > From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On > Behalf Of Dickinson, Ian > Sent: 14 April 2016 16:01 > To: Marco Schmidt ; address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] 2015-05 Discussion Period extended until > 13 May 2016 (Last /8 Allocation Criteria Revision) > > I object to this proposal as written. > > I do not believe there should be any distinction in policy based on a > notional arbitrary "size" of LIR. > > Ian > > -----Original Message----- > From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On > Behalf Of Marco Schmidt > Sent: 14 April 2016 13:42 > To: address-policy-wg at ripe.net > Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 > May 2016 (Last /8 Allocation Criteria Revision) > > Dear colleagues, > > The Discussion Period for the policy proposal 2015-05, "Last /8 Allocation > Criteria Revision" has been extended until 13 May 2016. > > The goal of this proposal is to allow LIRs to request an additional /22 > IPv4 allocation from the RIPE NCC every 18 months. > > The text of the proposal has been revised based on mailing list feedback > and we have published a new version (2.0) today. As a result, a new > Discussion Phase has started for the proposal. > > Some of the differences from version 1.0 include: > - Additional /22 IPv4 allocations can be only provided from address space > outside 185/8 > - Only LIRs with less than a /20 in total are eligible to receive > additional allocations > - LIRs must document their IPv6 deployment as part of the request > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2015-05 > > We encourage you to review this policy proposal and send your comments to < > address-policy-wg at ripe.net>. > > Regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC > > Information in this email including any attachments may be privileged, > confidential and is intended exclusively for the addressee. The views > expressed may not be official policy, but the personal views of the > originator. If you have received it in error, please notify the sender by > return e-mail and delete it from your system. You should not reproduce, > distribute, store, retransmit, use or disclose its contents to anyone. > Please note we reserve the right to monitor all e-mail communication > through our internal and external networks. SKY and the SKY marks are > trademarks of Sky plc and Sky International AG and are used under licence. > Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited > (Registration No. 2067075) and Sky Subscribers Services Limited > (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc > (Registration No. 2247735). All of the companies mentioned in this > paragraph are incorporated in England and Wales and share the same > registered office at Grant Way, Isleworth, Middlesex TW7 5QD. > Information in this email including any attachments may be privileged, > confidential and is intended exclusively for the addressee. The views > expressed may not be official policy, but the personal views of the > originator. If you have received it in error, please notify the sender by > return e-mail and delete it from your system. You should not reproduce, > distribute, store, retransmit, use or disclose its contents to anyone. > Please note we reserve the right to monitor all e-mail communication > through our internal and external networks. SKY and the SKY marks are > trademarks of Sky plc and Sky International AG and are used under licence. > Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited > (Registration No. 2067075) and Sky Subscribers Services Limited > (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc > (Registration No. 2247735). All of the companies mentioned in this > paragraph are incorporated in England and Wales and share the same > registered office at Grant Way, Isleworth, Middlesex TW7 5QD. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at rfc1035.com Thu Apr 14 18:01:58 2016 From: jim at rfc1035.com (Jim Reid) Date: Thu, 14 Apr 2016 17:01:58 +0100 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <570F9005.4090008@ripe.net> <20160414125115.GC25856@gir.theapt.org> Message-ID: > On 14 Apr 2016, at 15:34, Aled Morris wrote: > > I agree with the proposal because it makes it possible for recent entrants into the market to grow. I strongly disagree with the proposal because it will encourage LIRs to fritter away scarce IPv4 resources which need to be conserved so there will be at least some IPv4 space available for new entrants 10? 20? 30? years from now. LIRs who take advantage of this proposal would continue to fail to deal with the v4 run-out. That would be bad for everyone. > Speaking on behalf of such an entity, it's difficult to grow when you're limited to your one /22 in today's market. Tough. It?s difficult to get on a train long after it has left the station. New entrants presumably know what the current v4 allocation policy is and should plan accordingly. Everyone would like to grow their IPv4 networks but that just isn?t possible any more. > We (as an industry) are not there with IPv6 for this to be the only option. It's the only sane option. But there are others. Choose wisely. Changing address policy to speed up depletion of the NCC's last dregs of IPv4 is not wise. Doing that just because some LIRs -- not necessarily new entrants -- can?t or won?t face up to the reality of IPv4 exhaustion is even more unwise. This proposal, if adopted, would be also unfair on the LIRs who *already have* taken action to deal with the v4 run-out. That can?t possibly be right. > Ring-fencing 185/8 for new LIRs is sensible, this policy is really about recycling returned addresses and solves a real problem for a lot of recent new entrants. I?m far from convinced there is a ?real problem? here. If compelling arguments can be made to define the problem and solve it, let?s hear them! IMO this proposal is really about short-term gain for some at the expense of others, particularly tomorrow?s new LIRs. BTW what?s to stop an unscrupulous LIR from repeatedly requesting extra /22s (or whatever) through this proposal and then selling/transferring the space without updating the database? If they tried to do this today, they could only get away with it once because they?d only get one v4 allocation. From jim at rfc1035.com Thu Apr 14 18:13:07 2016 From: jim at rfc1035.com (Jim Reid) Date: Thu, 14 Apr 2016 17:13:07 +0100 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> Message-ID: <6186DAFC-20C1-4CEC-B027-F16518749004@rfc1035.com> > On 14 Apr 2016, at 16:59, Aled Morris wrote: > > If we limit the allocation of remaining space to brand new LIRs only, it means that small ISPs in their first growth spurt might be driven to form a second LIR to get that second /22 of space.. > > I know companies who've done this. It isn't sensible. True. But the NCC has ways to deal with those sorts of bad actors. Besides, the checks on a new LIR raise a reasonably high barrier for those who try to game the system in this way. > The proposal makes it possible to achieve the sensible result without resorting to stupid behaviour. It will however encourage new forms of stupid behaviour and enable attempts to game v4 allocation policy that would be harder for the NCC to police/detect. From Ian.Dickinson at sky.uk Thu Apr 14 18:17:10 2016 From: Ian.Dickinson at sky.uk (Dickinson, Ian) Date: Thu, 14 Apr 2016 16:17:10 +0000 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> Message-ID: <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> Aled, Let?s stop this being specific to my situation. I?m not arguing against 2015-05 because I work for a large LIR. I?m arguing against it because it is the wrong thing to do, full stop. We have a working policy, and we should stick with it. Anyway, I?ve registered my objection ? I?m done with this unless the text changes. Ian From: Aled Morris [mailto:aled.w.morris at googlemail.com] Sent: 14 April 2016 17:00 To: Dickinson, Ian Cc: Dominik Nowacki; address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) Ian, This policy isn't going to change the ability of a large organisation to grown since the amount of space we're talking about is relatively small, and totally trivial to an LIR with (the equivalent of) nearly 700 /22s. I don't think the policy fails the test of "fairness" simply because larger LIRs won't be getting addresses as the "benefit" of an additional /22 would be marginal for them anyway. I would hope that large LIRs don't make objections to this proposal just because they don't see any benefit to them - that come come across as selfish. If we limit the allocation of remaining space to brand new LIRs only, it means that small ISPs in their first growth spurt might be driven to form a second LIR to get that second /22 of space.. I know companies who've done this. It isn't sensible. The proposal makes it possible to achieve the sensible result without resorting to stupid behaviour. Aled Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aled.w.morris at googlemail.com Thu Apr 14 18:23:11 2016 From: aled.w.morris at googlemail.com (Aled Morris) Date: Thu, 14 Apr 2016 17:23:11 +0100 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> Message-ID: Sorry Ian I wasn't being personal but I do think the proposal benefits small LIRs and I have a vested interest in that regard. The other objection (Jim) seems to be "we should be all-out promoting IPv6" which I think is a laudable goal but unfortunately when used against proposals like this one means that more recent LIRs are disadvantaged against established companies with large pools of IPv4 to fall back on. It simply isn't possible, today, to build an ISP on an IPv6-only proposition. Aled On 14 April 2016 at 17:17, Dickinson, Ian wrote: > Aled, > > > > Let?s stop this being specific to my situation. I?m not arguing against > 2015-05 because I work for a large LIR. > > > > I?m arguing against it because it is the wrong thing to do, full stop. We > have a working policy, and we should stick with it. > > > > Anyway, I?ve registered my objection ? I?m done with this unless the text > changes. > > > > Ian > > > > *From:* Aled Morris [mailto:aled.w.morris at googlemail.com] > *Sent:* 14 April 2016 17:00 > *To:* Dickinson, Ian > *Cc:* Dominik Nowacki; address-policy-wg at ripe.net > *Subject:* Re: [address-policy-wg] 2015-05 Discussion Period extended > until 13 May 2016 (Last /8 Allocation Criteria Revision) > > > > Ian, > > > > This policy isn't going to change the ability of a large organisation to > grown since the amount of space we're talking about is relatively small, > and totally trivial to an LIR with (the equivalent of) nearly 700 /22s. > > > > I don't think the policy fails the test of "fairness" simply because > larger LIRs won't be getting addresses as the "benefit" of an additional > /22 would be marginal for them anyway. > > > > I would hope that large LIRs don't make objections to this proposal just > because they don't see any benefit to them - that come come across as > selfish. > > > > If we limit the allocation of remaining space to brand new LIRs only, it > means that small ISPs in their first growth spurt might be driven to form a > second LIR to get that second /22 of space.. > > > > I know companies who've done this. It isn't sensible. The proposal makes > it possible to achieve the sensible result without resorting to stupid > behaviour. > > > > Aled > > > Information in this email including any attachments may be privileged, > confidential and is intended exclusively for the addressee. The views > expressed may not be official policy, but the personal views of the > originator. If you have received it in error, please notify the sender by > return e-mail and delete it from your system. You should not reproduce, > distribute, store, retransmit, use or disclose its contents to anyone. > Please note we reserve the right to monitor all e-mail communication > through our internal and external networks. SKY and the SKY marks are > trademarks of Sky plc and Sky International AG and are used under licence. > Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited > (Registration No. 2067075) and Sky Subscribers Services Limited > (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc > (Registration No. 2247735). All of the companies mentioned in this > paragraph are incorporated in England and Wales and share the same > registered office at Grant Way, Isleworth, Middlesex TW7 5QD. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at rfc1035.com Thu Apr 14 18:24:47 2016 From: jim at rfc1035.com (Jim Reid) Date: Thu, 14 Apr 2016 17:24:47 +0100 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> Message-ID: <81395D12-5462-47A1-B9FD-C77DF7F63537@rfc1035.com> > On 14 Apr 2016, at 17:17, Dickinson, Ian wrote: > > I?m arguing against it because it is the wrong thing to do, full stop. +100 > We have a working policy, and we should stick with it. +100 From tom.hill at bytemark.co.uk Thu Apr 14 18:31:39 2016 From: tom.hill at bytemark.co.uk (Tom Hill) Date: Thu, 14 Apr 2016 17:31:39 +0100 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <570F9005.4090008@ripe.net> <20160414125115.GC25856@gir.theapt.org> Message-ID: <570FC5EB.3030106@bytemark.co.uk> On 14/04/16 17:01, Jim Reid wrote: > I strongly disagree with the proposal because it will encourage LIRs > to fritter away scarce IPv4 resources which need to be conserved so > there will be at least some IPv4 space available for new entrants 10? > 20? 30? years from now. > IMO this proposal is really about short-term gain for some at the > expense of others, particularly tomorrow?s new LIRs. These, for me, are the two most important points yet. 2015-05, like all previous attempts to change the "last /8" address policy, have ignored them. If the pro-policy argument is that "IPv6 is taking too long, we need more IPv4 today" then how are you going to feel in 15 years when you still need some IPv4, and there isn't any? One could say that you might be "shooting yourself in the foot" by adopting this policy - especially if you don't work for the same Company as you do today. Regards, -- Tom Hill Network Engineer Bytemark Hosting http://www.bytemark.co.uk/ tel. +44 (0) 1904 890 890 From randy at psg.com Thu Apr 14 19:24:29 2016 From: randy at psg.com (Randy Bush) Date: Fri, 15 Apr 2016 02:24:29 +0900 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <570F9005.4090008@ripe.net> References: <570F9005.4090008@ripe.net> Message-ID: i do not support pigs at the last /8 trough the purpose of the single last /8 allocation was to allow NEW ENTRY. pigs coming back to the trough every 18 months is not new anything. randy From jim at rfc1035.com Thu Apr 14 19:29:03 2016 From: jim at rfc1035.com (Jim Reid) Date: Thu, 14 Apr 2016 18:29:03 +0100 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> Message-ID: > On 14 Apr 2016, at 17:23, Aled Morris wrote: > > The other objection (Jim) seems to be "we should be all-out promoting IPv6? I said no such thing. There are a number of ways for organisations to deal with IPv4 exhaustion. These include (but are not limited to) IPv6 deployment; closing your eyes, sticking your fingers in your ears and pretending the problem does not exist; NAT; ALG; acquiring addresses from the secondary market; buying an address holder with lots of unused space; etc, etc. IMO IPv6 deployment seems to be the least worst of these choices but whatever choice someone makes is up to them. After all, they should know which option works best for their network. YMMV. My objections to 2015-05 are as follows: 1) It will deplete the remaining pool of IPv4 space at a faster rate than is sensible or reasonable. 2) It will disadvantage new entrants who need IPv4 once the RIRs have run out sooner than they should have done. 3) It allows LIRs to continue to ignore the IPv4 run-out because they could just keep going back to the RIR and get yet another IPv4 allocation. 4) It disadvantages existing LIRs who have already taken action to address IPv4 exhaustion. 5) It enables new and unwelcome ways to scam address space and/or compromise the integrity of the RIPE database. 6) There?s no clear problem statement, let alone an explanation how this proposal solves whatever that problem might be or why other solutions are unsuitable. ?Some LIRs want to grow their networks and ignore the IPv4 run-out? is not a sound problem statement IMO. 7) It will discourage address recycling. Why return unused space to IANA or the RIR if they?re just going to give it away to LIRs who can?t/won?t take proper steps to deal with the IPv4 run-out? There?s no mention of IPv6 in the above list. > recent LIRs are disadvantaged against established companies with large pools of IPv4 to fall back on. Tough. That was then. This is now. The circumstances an policies that prevailed 10-20-30 years ago don?t apply today. We can only do the best (or least-worst) job of allocating the remaining IPv4 space in a fair and reasonable manner. 2015-05 does not achieve that. In fact it does the opposite. > It simply isn't possible, today, to build an ISP on an IPv6-only proposition. Nobody was saying or even suggesting it was. At least I don?t think anyone was saying that. Similarly, it simply won?t be possible N years from now for someone to build their IPv6 only network and have connectivity to the legacy Internet unless they can get some IPv4 space. From aled.w.morris at googlemail.com Thu Apr 14 19:40:58 2016 From: aled.w.morris at googlemail.com (Aled Morris) Date: Thu, 14 Apr 2016 18:40:58 +0100 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> Message-ID: OK I see what you are saying now. One one particular point, I'm as concerned as anyone about the possibility of bad actors "gaming the system" to get more address space. There's no perfect system but if the weight of opinion is that changing the rules might well make things worse then I agree we shouldn't do it. Aled On 14 April 2016 at 18:29, Jim Reid wrote: > >> On 14 Apr 2016, at 17:23, Aled Morris wrote: >> >> The other objection (Jim) seems to be "we should be all-out promoting IPv6? > > I said no such thing. > > There are a number of ways for organisations to deal with IPv4 exhaustion. These include (but are not limited to) IPv6 deployment; closing your eyes, sticking your fingers in your ears and pretending the problem does not exist; NAT; ALG; acquiring addresses from the secondary market; buying an address holder with lots of unused space; etc, etc. IMO IPv6 deployment seems to be the least worst of these choices but whatever choice someone makes is up to them. After all, they should know which option works best for their network. YMMV. > > My objections to 2015-05 are as follows: > > 1) It will deplete the remaining pool of IPv4 space at a faster rate than is sensible or reasonable. > 2) It will disadvantage new entrants who need IPv4 once the RIRs have run out sooner than they should have done. > 3) It allows LIRs to continue to ignore the IPv4 run-out because they could just keep going back to the RIR and get yet another IPv4 allocation. > 4) It disadvantages existing LIRs who have already taken action to address IPv4 exhaustion. > 5) It enables new and unwelcome ways to scam address space and/or compromise the integrity of the RIPE database. > 6) There?s no clear problem statement, let alone an explanation how this proposal solves whatever that problem might be or why other solutions are unsuitable. ?Some LIRs want to grow their networks and ignore the IPv4 run-out? is not a sound problem statement IMO. > 7) It will discourage address recycling. Why return unused space to IANA or the RIR if they?re just going to give it away to LIRs who can?t/won?t take proper steps to deal with the IPv4 run-out? > > There?s no mention of IPv6 in the above list. > >> recent LIRs are disadvantaged against established companies with large pools of IPv4 to fall back on. > > Tough. That was then. This is now. The circumstances an policies that prevailed 10-20-30 years ago don?t apply today. We can only do the best (or least-worst) job of allocating the remaining IPv4 space in a fair and reasonable manner. 2015-05 does not achieve that. In fact it does the opposite. > >> It simply isn't possible, today, to build an ISP on an IPv6-only proposition. > > Nobody was saying or even suggesting it was. At least I don?t think anyone was saying that. > > Similarly, it simply won?t be possible N years from now for someone to build their IPv6 only network and have connectivity to the legacy Internet unless they can get some IPv4 space. > From dominik at clouvider.co.uk Thu Apr 14 19:27:25 2016 From: dominik at clouvider.co.uk (Dominik Nowacki) Date: Thu, 14 Apr 2016 17:27:25 +0000 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <570F9005.4090008@ripe.net> Message-ID: Perhaps you'd care to keep this discussion Civil? Kind Regards, Dom -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Randy Bush Sent: 14 April 2016 18:24 To: Marco Schmidt Cc: RIPE address policy WG Subject: Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) i do not support pigs at the last /8 trough the purpose of the single last /8 allocation was to allow NEW ENTRY. pigs coming back to the trough every 18 months is not new anything. randy From rgori at wirem.net Thu Apr 14 20:33:01 2016 From: rgori at wirem.net (Riccardo Gori) Date: Thu, 14 Apr 2016 20:33:01 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <20160414153718.GA10236@jobspension.ja.net> References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <20160414153718.GA10236@jobspension.ja.net> Message-ID: <570FE25D.2070408@wirem.net> Hi Rob, just about three stars and not more: with 3 stars you have a working IPv6 deployment but you are not listed as RIPEness 'cause of absence of reverse delegation for IPv6 If you host DNS servers for reverse delegation outside of you network on a IPv4 only provider you can't reach 4 or 5 stars even with a perfectly working IPv6 deployment 3 stars looked to be a first good step to "taste" IPv6 hope this helps regards Riccardo Il 14/04/2016 17:37, Rob Evans ha scritto: > Hi, > >> I do not believe there should be any distinction in policy based >> on a notional arbitrary "size" of LIR. > I almost agree with you, and it's the difference between a LIR that > holds a /21 and one that holds a /20 that's concerning me, but with > a feeling that an extra /22 may be of far more use to an LIR that > only holds a /22 to one that has, say, /14 of space. > > The RIPE community has tried to walk a line between keeping IPv4 > addresses back to ensure new entrants can join the market, and not > needlessly hoarding addresses. The problem with that approach is > that we are forever doomed to make small adjustments to the policy > to keep that balance. > > Give or take a bit of fluctuation when the IANA doles out a bit > more returned space, the pool of available IPv4 space the NCC has > is about the same now as it was three years ago, but we're about > half-way through 185/8: > > https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustion/ipv4-available-pool-graph > > Interestingly that graph doesn't appear to show much of a change > following the "multiple LIR" decision at the last meeting. > > One /16 out of the final /8 is reserved for some future need, which > means that there are ~16,320 /22s in that block. Let's say that's > in the same order of magniture as there are RIPE NCC members (12,830 > at the end of 2015), but it's not a large breathing gap. > > The NCC only has about 8,000 /22s outside 185/8 (at the moment), > so it all depends on what we want to classify as distributing them > fairly. Another /22 for those that need it? How much will that > pool continue to grow? Is there a distribution of number of members > by address space they hold? > > I'm also not sure about the "RIPEness" requirement. It's an > interesting metric, but why three rather than four? Should we be > encoding in policy a requirement that the NCC can change at will? > My personal opinion (working on a network that's offered IPv6 in > some way shape or form for 19 years), is that how I run my network > is my (or perhaps more importantly, my customers') business. > > Still, at least it gives us something to talk about in Address > Policy. Life would be boring otherwise. > > Cheers, > Rob > -- Ing. Riccardo Gori e-mail: rgori at wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info at wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logoWirem_4cm_conR.jpg Type: image/jpeg Size: 41774 bytes Desc: not available URL: From ebais at a2b-internet.com Thu Apr 14 22:07:06 2016 From: ebais at a2b-internet.com (Erik Bais) Date: Thu, 14 Apr 2016 22:07:06 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <570F9005.4090008@ripe.net> References: <570F9005.4090008@ripe.net> Message-ID: <002301d19689$48432160$d8c96420$@a2b-internet.com> Hi Radu and Ricardo (& AP community members), I looked at the policy text and also checked if there would be an option to just ?hand out? an additional /22 to all current LIR?s.. If we currently have about 12.000 members .. and hand out additional /22?s to each of them, it will cost 12 milj addresses ( more or less..) ( as it would be more fair than discriminating on current size and age of an LIR ? ) The current pool is about 16.4 milj addresses left.. and in the last 3 years, they have handed out 9 milj. addresses. As there probably won?t come more than 32.000 addresses back from IANA .. and not much more space to be expected from de-registration of PI space.. The pool won?t grow much more than it is currently ? So handing out 12 milj. addresses in a single gift.. without the hard requirement to not allow final /8 policy received IP space to be transferred, will most likely only increase the run-out of the IP space and not fix anything.. The real issue is, this policy change won?t fix anything at all ? it will make things impossible for the near future. The replenishment from IANA will stop, so the actual pool will go down. With the actual rate of 9 milj per 3 years.. that means that at the current rate, the current pool will last for about 5.3 years. ( looking at an avg of 3 milj per year. ) If we hand out 12 milj. Addresses of the 16.4 milj. We have 4.4 milj. addresses left.. meaning that we will have a full run-out within 18 months. These are the numbers that we are currently looking at. They might change a bit, off by a couple months perhaps.. but the difference is an issue of fully running out within 18 months or 5.3 years. So as we need more time for companies to fully move over to IPv6 .. and we need to be able to hand out a /22 IPv4 for CGNAT for new entrance to the market in order to be able to compete.. ( As that was the actual reason to implement the last /8 policy..) So taking all this in mind, this policy change is a bad decision imho. Yes I know that you are trying to discriminate in the policy by saying, no transfers done in the past, not more than 4k IPv4 etc etc.. but that is just semantics.. it won?t fix the overall policy you are trying to implement. So perhaps a long answer to say that I won't support it. Regards, Erik Bais From niall.oreilly at ucd.ie Fri Apr 15 00:33:14 2016 From: niall.oreilly at ucd.ie (Niall O'Reilly) Date: Thu, 14 Apr 2016 23:33:14 +0100 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <570F9005.4090008@ripe.net> <20160414125115.GC25856@gir.theapt.org> Message-ID: On 14 Apr 2016, at 17:01, Jim Reid wrote: > I strongly disagree with the proposal what Jim said, which you don't need to see again. Well said, Jim. /Niall From remco.vanmook at gmail.com Fri Apr 15 00:50:15 2016 From: remco.vanmook at gmail.com (remco van mook) Date: Thu, 14 Apr 2016 22:50:15 +0000 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <570F9005.4090008@ripe.net> References: <570F9005.4090008@ripe.net> Message-ID: Dear colleagues, I'd like to reiterate my objection to this proposal. Anyone who thinks another block of 1,000 addresses is going to help them float their business is in my opinion delusional (because the next step would be an extra 2,000, then 4,000, ..). The problem is not that you're getting a /22 - the problem is that we're out of space, never to come back. I also object to the notion that new entrants who joined the game recently have any more entitlement than new entrants 2 years from now. The final /8 policy in the RIPE region has been, in my opinion, a remarkable success because there's actually still space left to haggle about. What does need fixing is the fact that there are a few obvious loopholes that are now being used to contravene the intention of the policy, and are being used as a rationale for this proposal. Kind regards, Remco (no hats) On Thu, Apr 14, 2016 at 2:43 PM Marco Schmidt wrote: > Dear colleagues, > > The Discussion Period for the policy proposal 2015-05, "Last /8 > Allocation Criteria Revision" has been extended until 13 May 2016. > > The goal of this proposal is to allow LIRs to request an additional /22 > IPv4 allocation from the RIPE NCC every 18 months. > > The text of the proposal has been revised based on mailing list feedback > and we have published a new version (2.0) today. As a result, a new > Discussion Phase has started for the proposal. > > Some of the differences from version 1.0 include: > - Additional /22 IPv4 allocations can be only provided from address > space outside 185/8 > - Only LIRs with less than a /20 in total are eligible to receive > additional allocations > - LIRs must document their IPv6 deployment as part of the request > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2015-05 > > We encourage you to review this policy proposal and send your comments > to . > > Regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marty at akamai.com Fri Apr 15 01:03:23 2016 From: marty at akamai.com (Hannigan, Martin) Date: Thu, 14 Apr 2016 23:03:23 +0000 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <570F9005.4090008@ripe.net>, Message-ID: I agree with you. I'm also not in favor. Best, Marty On Apr 14, 2016, at 15:50, remco van mook > wrote: Dear colleagues, I'd like to reiterate my objection to this proposal. Anyone who thinks another block of 1,000 addresses is going to help them float their business is in my opinion delusional (because the next step would be an extra 2,000, then 4,000, ..). The problem is not that you're getting a /22 - the problem is that we're out of space, never to come back. I also object to the notion that new entrants who joined the game recently have any more entitlement than new entrants 2 years from now. The final /8 policy in the RIPE region has been, in my opinion, a remarkable success because there's actually still space left to haggle about. What does need fixing is the fact that there are a few obvious loopholes that are now being used to contravene the intention of the policy, and are being used as a rationale for this proposal. Kind regards, Remco (no hats) On Thu, Apr 14, 2016 at 2:43 PM Marco Schmidt > wrote: Dear colleagues, The Discussion Period for the policy proposal 2015-05, "Last /8 Allocation Criteria Revision" has been extended until 13 May 2016. The goal of this proposal is to allow LIRs to request an additional /22 IPv4 allocation from the RIPE NCC every 18 months. The text of the proposal has been revised based on mailing list feedback and we have published a new version (2.0) today. As a result, a new Discussion Phase has started for the proposal. Some of the differences from version 1.0 include: - Additional /22 IPv4 allocations can be only provided from address space outside 185/8 - Only LIRs with less than a /20 in total are eligible to receive additional allocations - LIRs must document their IPv6 deployment as part of the request You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2015-05 We encourage you to review this policy proposal and send your comments to >. Regards, Marco Schmidt Policy Development Officer RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From tore at fud.no Fri Apr 15 06:51:21 2016 From: tore at fud.no (Tore Anderson) Date: Fri, 15 Apr 2016 06:51:21 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <570F9005.4090008@ripe.net> <20160414125115.GC25856@gir.theapt.org> Message-ID: <20160415065121.12e36e72@echo.ms.redpill-linpro.com> * "Niall O'Reilly" > On 14 Apr 2016, at 17:01, Jim Reid wrote: > > > I strongly disagree with the proposal > > what Jim said, which you don't need to see again. > Well said, Jim. +1 Tore From rgori at wirem.net Fri Apr 15 07:48:36 2016 From: rgori at wirem.net (Riccardo Gori) Date: Fri, 15 Apr 2016 07:48:36 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <570F9005.4090008@ripe.net> Message-ID: <571080B4.70101@wirem.net> Good Morning Remco, Good Morning List, with all respect I don't see a "remarkable success" in current last /8 policy. We are dealing with the same amount of space as September 2012 that in the meanwhile has been abused in several ways and there are really no incentives to IPv6 adoption. There was only one requirement to obtain one IPv4 /22: request and obtain at least from /32 IPv6 to a maximum of /29 IPv6. Am I wrong or this requirement has been removed?!?! Please explain that to a new entrant... What does it mean? "we are running out. here your crumbs, sorry we have no solution" ?!? If for you last /8 policy is a success to me IPv6 incentives policies looks absent. We completly failed from this point of view. If you look at this where IPv4 exhaustion took place IPv6 is strongly gowing: https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption&tab=per-country-ipv6-adoption I think this policy is not for faster exhaustion but for "farier exhaustion" and is offering a path to go over IPv4 while still needing it to grow. kind regards Riccardo Il 15/04/2016 00:50, remco van mook ha scritto: > Dear colleagues, > > I'd like to reiterate my objection to this proposal. Anyone who thinks > another block of 1,000 addresses is going to help them float their > business is in my opinion delusional (because the next step would be > an extra 2,000, then 4,000, ..). The problem is not that you're > getting a /22 - the problem is that we're out of space, never to come > back. I also object to the notion that new entrants who joined the > game recently have any more entitlement than new entrants 2 years from > now. > > The final /8 policy in the RIPE region has been, in my opinion, a > remarkable success because there's actually still space left to haggle > about. What does need fixing is the fact that there are a few obvious > loopholes that are now being used to contravene the intention of the > policy, and are being used as a rationale for this proposal. > > Kind regards, > > Remco > (no hats) > > On Thu, Apr 14, 2016 at 2:43 PM Marco Schmidt > wrote: > > Dear colleagues, > > The Discussion Period for the policy proposal 2015-05, "Last /8 > Allocation Criteria Revision" has been extended until 13 May 2016. > > The goal of this proposal is to allow LIRs to request an > additional /22 > IPv4 allocation from the RIPE NCC every 18 months. > > The text of the proposal has been revised based on mailing list > feedback > and we have published a new version (2.0) today. As a result, a new > Discussion Phase has started for the proposal. > > Some of the differences from version 1.0 include: > - Additional /22 IPv4 allocations can be only provided from address > space outside 185/8 > - Only LIRs with less than a /20 in total are eligible to receive > additional allocations > - LIRs must document their IPv6 deployment as part of the request > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2015-05 > > We encourage you to review this policy proposal and send your comments > to >. > > Regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC > -- Ing. Riccardo Gori e-mail: rgori at wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info at wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logoWirem_4cm_conR.jpg Type: image/jpeg Size: 41774 bytes Desc: not available URL: From ebais at a2b-internet.com Fri Apr 15 09:36:58 2016 From: ebais at a2b-internet.com (Erik Bais) Date: Fri, 15 Apr 2016 09:36:58 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <571080B4.70101@wirem.net> References: <570F9005.4090008@ripe.net> <571080B4.70101@wirem.net> Message-ID: <007301d196e9$9b28be20$d17a3a60$@a2b-internet.com> Riccardo, > with all respect I don't see a "remarkable success" in current last /8 policy. The fact that you don?t see it, doesn?t make it less true. RIPE IPv4 is out ? the reservation of space for IXP?s and other uses ( like future new entrance ) doesn?t change that. This is not something we have to explain .. this is not something that we will change. The /22 IPv4 is not for new entrance to assign to customers.. it is to enable them to communicate via a CGNAT from a v6 world to a v4 world. If you don?t use the obtained v4 space for the intended use, it will never be enough and you will always feel incorrectly treated ? This policy proposal (with all respect to you and Radu and good intentions) needs to stop as it gives people hope on something that isn?t there ... Regards, Erik Bais Van: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] Namens Riccardo Gori Verzonden: vrijdag 15 april 2016 7:49 Aan: address-policy-wg at ripe.net; remco.vanmook at gmail.com Onderwerp: Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) Good Morning Remco, Good Morning List, with all respect I don't see a "remarkable success" in current last /8 policy. We are dealing with the same amount of space as September 2012 that in the meanwhile has been abused in several ways and there are really no incentives to IPv6 adoption. There was only one requirement to obtain one IPv4 /22: request and obtain at least from /32 IPv6 to a maximum of /29 IPv6. Am I wrong or this requirement has been removed?!?! Please explain that to a new entrant... What does it mean? "we are running out. here your crumbs, sorry we have no solution" ?!? If for you last /8 policy is a success to me IPv6 incentives policies looks absent. We completly failed from this point of view. If you look at this where IPv4 exhaustion took place IPv6 is strongly gowing: https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption &tab=per-country-ipv6-adoption I think this policy is not for faster exhaustion but for "farier exhaustion" and is offering a path to go over IPv4 while still needing it to grow. kind regards Riccardo Il 15/04/2016 00:50, remco van mook ha scritto: Dear colleagues, I'd like to reiterate my objection to this proposal. Anyone who thinks another block of 1,000 addresses is going to help them float their business is in my opinion delusional (because the next step would be an extra 2,000, then 4,000, ..). The problem is not that you're getting a /22 - the problem is that we're out of space, never to come back. I also object to the notion that new entrants who joined the game recently have any more entitlement than new entrants 2 years from now. The final /8 policy in the RIPE region has been, in my opinion, a remarkable success because there's actually still space left to haggle about. What does need fixing is the fact that there are a few obvious loopholes that are now being used to contravene the intention of the policy, and are being used as a rationale for this proposal. Kind regards, Remco (no hats) On Thu, Apr 14, 2016 at 2:43 PM Marco Schmidt > wrote: Dear colleagues, The Discussion Period for the policy proposal 2015-05, "Last /8 Allocation Criteria Revision" has been extended until 13 May 2016. The goal of this proposal is to allow LIRs to request an additional /22 IPv4 allocation from the RIPE NCC every 18 months. The text of the proposal has been revised based on mailing list feedback and we have published a new version (2.0) today. As a result, a new Discussion Phase has started for the proposal. Some of the differences from version 1.0 include: - Additional /22 IPv4 allocations can be only provided from address space outside 185/8 - Only LIRs with less than a /20 in total are eligible to receive additional allocations - LIRs must document their IPv6 deployment as part of the request You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2015-05 We encourage you to review this policy proposal and send your comments to >. Regards, Marco Schmidt Policy Development Officer RIPE NCC -- Ing. Riccardo Gori e-mail: rgori at wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info at wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 4400 bytes Desc: not available URL: From swmike at swm.pp.se Fri Apr 15 09:45:52 2016 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 15 Apr 2016 09:45:52 +0200 (CEST) Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <20160415065121.12e36e72@echo.ms.redpill-linpro.com> References: <570F9005.4090008@ripe.net> <20160414125115.GC25856@gir.theapt.org> <20160415065121.12e36e72@echo.ms.redpill-linpro.com> Message-ID: On Fri, 15 Apr 2016, Tore Anderson wrote: > * "Niall O'Reilly" > >> On 14 Apr 2016, at 17:01, Jim Reid wrote: >> >>> I strongly disagree with the proposal >> >> what Jim said, which you don't need to see again. >> Well said, Jim. > > +1 I agree with people above, I want to keep the last /8 for new future entrants with current policy, not deplete quicker. -- Mikael Abrahamsson email: swmike at swm.pp.se From ggiannou at gmail.com Fri Apr 15 09:48:41 2016 From: ggiannou at gmail.com (George Giannousopoulos) Date: Fri, 15 Apr 2016 10:48:41 +0300 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <007301d196e9$9b28be20$d17a3a60$@a2b-internet.com> References: <570F9005.4090008@ripe.net> <571080B4.70101@wirem.net> <007301d196e9$9b28be20$d17a3a60$@a2b-internet.com> Message-ID: Hello all, I fully agree with Erik and the rest. I still don't support this proposal. -- George On Fri, Apr 15, 2016 at 10:36 AM, Erik Bais wrote: > Riccardo, > > > > > with all respect I don't see a "remarkable success" in current last /8 > policy. > > The fact that you don?t see it, doesn?t make it less true. > > > > RIPE IPv4 is out ? the reservation of space for IXP?s and other uses ( > like future new entrance ) doesn?t change that. > > > > This is not something we have to explain .. this is not something that we > will change. > > > > The /22 IPv4 is not for new entrance to assign to customers.. it is to > enable them to communicate via a CGNAT from a v6 world to a v4 world. > > > > If you don?t use the obtained v4 space for the intended use, it will never > be enough and you will always feel incorrectly treated ? > > > > This policy proposal (with all respect to you and Radu and good > intentions) needs to stop as it gives people hope on something that isn?t > there ... > > > > Regards, > > Erik Bais > > > > *Van:* address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] *Namens > *Riccardo Gori > *Verzonden:* vrijdag 15 april 2016 7:49 > *Aan:* address-policy-wg at ripe.net; remco.vanmook at gmail.com > *Onderwerp:* Re: [address-policy-wg] 2015-05 Discussion Period extended > until 13 May 2016 (Last /8 Allocation Criteria Revision) > > > > Good Morning Remco, Good Morning List, > > with all respect I don't see a "remarkable success" in current last /8 > policy. > We are dealing with the same amount of space as September 2012 that in the > meanwhile has been abused in several ways and there are really no > incentives to IPv6 adoption. > > There was only one requirement to obtain one IPv4 /22: request and obtain > at least from /32 IPv6 to a maximum of /29 IPv6. > Am I wrong or this requirement has been removed?!?! Please explain that to > a new entrant... > What does it mean? "we are running out. here your crumbs, sorry we have no > solution" ?!? > > If for you last /8 policy is a success to me IPv6 incentives policies > looks absent. We completly failed from this point of view. > If you look at this where IPv4 exhaustion took place IPv6 is strongly > gowing: > https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption&tab=per-country-ipv6-adoption > > I think this policy is not for faster exhaustion but for "farier > exhaustion" and is offering a path to go over IPv4 while still needing it > to grow. > > kind regards > Riccardo > > Il 15/04/2016 00:50, remco van mook ha scritto: > > Dear colleagues, > > > > I'd like to reiterate my objection to this proposal. Anyone who thinks > another block of 1,000 addresses is going to help them float their business > is in my opinion delusional (because the next step would be an extra 2,000, > then 4,000, ..). The problem is not that you're getting a /22 - the problem > is that we're out of space, never to come back. I also object to the notion > that new entrants who joined the game recently have any more entitlement > than new entrants 2 years from now. > > > > The final /8 policy in the RIPE region has been, in my opinion, a > remarkable success because there's actually still space left to haggle > about. What does need fixing is the fact that there are a few obvious > loopholes that are now being used to contravene the intention of the > policy, and are being used as a rationale for this proposal. > > > > Kind regards, > > > > Remco > > (no hats) > > > > On Thu, Apr 14, 2016 at 2:43 PM Marco Schmidt wrote: > > Dear colleagues, > > The Discussion Period for the policy proposal 2015-05, "Last /8 > Allocation Criteria Revision" has been extended until 13 May 2016. > > The goal of this proposal is to allow LIRs to request an additional /22 > IPv4 allocation from the RIPE NCC every 18 months. > > The text of the proposal has been revised based on mailing list feedback > and we have published a new version (2.0) today. As a result, a new > Discussion Phase has started for the proposal. > > Some of the differences from version 1.0 include: > - Additional /22 IPv4 allocations can be only provided from address > space outside 185/8 > - Only LIRs with less than a /20 in total are eligible to receive > additional allocations > - LIRs must document their IPv6 deployment as part of the request > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2015-05 > > We encourage you to review this policy proposal and send your comments > to . > > Regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC > > > > -- > > Ing. Riccardo Gori > > e-mail: rgori at wirem.net > > Mobile: +39 339 8925947 > > Mobile: +34 602 009 437 > > Profile: https://it.linkedin.com/in/riccardo-gori-74201943 > > WIREM Fiber Revolution > > Net-IT s.r.l. > > Via Cesare Montanari, 2 > > 47521 Cesena (FC) > > Tel +39 0547 1955485 > > Fax +39 0547 1950285 > > > > -------------------------------------------------------------------- > > CONFIDENTIALITY NOTICE > > This message and its attachments are addressed solely to the persons > > above and may contain confidential information. If you have received > > the message in error, be informed that any use of the content hereof > > is prohibited. Please return it immediately to the sender and delete > > the message. Should you have any questions, please contact us by re- > > plying to info at wirem.net > > Thank you > > WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) > > -------------------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 4400 bytes Desc: not available URL: From phessler at theapt.org Fri Apr 15 10:16:45 2016 From: phessler at theapt.org (Peter Hessler) Date: Fri, 15 Apr 2016 10:16:45 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <44515e0cc3a4bab757dbf0bab60999fe@gadago.net> References: <570F9005.4090008@ripe.net> <20160414125115.GC25856@gir.theapt.org> <44515e0cc3a4bab757dbf0bab60999fe@gadago.net> Message-ID: <20160415081645.GE25856@gir.theapt.org> If you need/want more IPv4 addresses, the marketplace is available. RIPE should not give more addresses to people that already have some. Growth into a market that should be killed, should not be encouraged by RIPE. On 2016 Apr 14 (Thu) at 15:51:56 +0100 (+0100), ripe at scholarwebservices.com wrote: : : :Hello, : :I am in favour of the proposal. Similar to Aled's comments below, we are :a small entity that is restricted to growth with a single /22. I believe :the 185/8 should be restricted to new entrants but allowing :recycled/returned address space (outside of the 185/8) to be allocated, :providing the LIR has less than a /20 in total. : :Kind regards, : :Gavin : :On 2016-04-14 15:34, Aled Morris wrote: : :> Peter, :> :> I agree with the proposal because it makes it possible for recent entrants into the market to grow. Speaking on behalf of such an entity, it's difficult to grow when you're limited to your one /22 in today's market. We (as an industry) are not there with IPv6 for this to be the only option. :> :> Ring-fencing 185/8 for new LIRs is sensible, this policy is really about recycling returned addresses and solves a real problem for a lot of recent new entrants. :> :> Of course we are all working on introducing IPv6 but I think we need this policy as it complements the allocation from 185/8 for new LIRs with a fair mechanism for nurturing LIRs who have filled their initial allocation. :> :> Aled :> :> On 14 April 2016 at 13:51, Peter Hessler wrote: :> :>> While I appreciate that there are more restricions on who is eligable to :>> receive new allocations, I am still opposed to this proposal for the :>> simple reason of "it depletes the IPv4 pool faster, and causes problems :>> for new entrants". :>> :>> -- :>> Anybody can win, unless there happens to be a second entry. : -- The only way to get rid of a temptation is to yield to it. -- Oscar Wilde From tjc at ecs.soton.ac.uk Fri Apr 15 10:30:29 2016 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Fri, 15 Apr 2016 09:30:29 +0100 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <570F9005.4090008@ripe.net> Message-ID: > On Apr 14, 2016, at 15:50, remco van mook > wrote: > >> Dear colleagues, >> >> I'd like to reiterate my objection to this proposal. Anyone who thinks another block of 1,000 addresses is going to help them float their business is in my opinion delusional (because the next step would be an extra 2,000, then 4,000, ..). The problem is not that you're getting a /22 - the problem is that we're out of space, never to come back. I also object to the notion that new entrants who joined the game recently have any more entitlement than new entrants 2 years from now. >> >> The final /8 policy in the RIPE region has been, in my opinion, a remarkable success because there's actually still space left to haggle about. What does need fixing is the fact that there are a few obvious loopholes that are now being used to contravene the intention of the policy, and are being used as a rationale for this proposal. I agree with Remco, and thus share his objection. Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjc at ecs.soton.ac.uk Fri Apr 15 10:33:24 2016 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Fri, 15 Apr 2016 09:33:24 +0100 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <571080B4.70101@wirem.net> References: <570F9005.4090008@ripe.net> <571080B4.70101@wirem.net> Message-ID: > On 15 Apr 2016, at 06:48, Riccardo Gori wrote: > there are really no incentives to IPv6 adoption. Really? Tim From gert at space.net Fri Apr 15 10:39:22 2016 From: gert at space.net (Gert Doering) Date: Fri, 15 Apr 2016 10:39:22 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> Message-ID: <20160415083922.GN56633@Space.Net> Hi, On Thu, Apr 14, 2016 at 04:59:55PM +0100, Aled Morris wrote: > I would hope that large LIRs don't make objections to this proposal just > because they don't see any benefit to them - that come come across as > selfish. Objections or support for a proposal is made by individuals, not by organizations. Individuals may happen to work for large or small LIRs, or not for a LIR at all - *but* people with lots of experience, and based on that, some foresight, might end up in senior positions in large LIRs... so look at the arguments, not at what domain is in the mail address. (Turning the argument around: "small LIRs asking *for* this proposal" is selfish as well, 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: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From gert at space.net Fri Apr 15 10:41:56 2016 From: gert at space.net (Gert Doering) Date: Fri, 15 Apr 2016 10:41:56 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> Message-ID: <20160415084156.GO56633@Space.Net> Hi, On Thu, Apr 14, 2016 at 05:23:11PM +0100, Aled Morris wrote: > The other objection (Jim) seems to be "we should be all-out promoting IPv6" > which I think is a laudable goal but unfortunately when used against > proposals like this one means that more recent LIRs are disadvantaged > against established companies with large pools of IPv4 to fall back on. It > simply isn't possible, today, to build an ISP on an IPv6-only proposition. Please do not forget the fact that small LIRs are not *disadvantaged* by this policy, but actually *advantaged*. If we didn't have this policy, but just ran out like ARIN did, small startup LIRs today would not be able to get *anything*. Now they can get a /22. Is that enough? No. Can we fix it, without taking away space that *other* small LIRs might want to have, in a few years time? 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: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rhe at nosc.ja.net Fri Apr 15 10:42:07 2016 From: rhe at nosc.ja.net (Rob Evans) Date: Fri, 15 Apr 2016 09:42:07 +0100 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <570FE25D.2070408@wirem.net> References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <20160414153718.GA10236@jobspension.ja.net> <570FE25D.2070408@wirem.net> Message-ID: <20160415084207.GA10726@jobspension.ja.net> Hi Riccardo, Thanks for the reply. > with 3 stars you have a working IPv6 deployment but you are not listed as > RIPEness 'cause of absence of reverse delegation for IPv6 > If you host DNS servers for reverse delegation outside of you network on a > IPv4 only provider you can't reach 4 or 5 stars even with a perfectly > working IPv6 deployment > 3 stars looked to be a first good step to "taste" IPv6 This is what leads me to think the policy panders to one specific category of LIR. Either have no IPv6 requirements, or require IPv6 available to all customers. I think it is reckless to quadruple the amount of scarce IPv4 space given to new entrants at the cost to future entrants, and in case it wasn't clear from yesterday's email, I'm afraid I do not support this policy. All the best, Rob From phessler at theapt.org Fri Apr 15 10:50:32 2016 From: phessler at theapt.org (Peter Hessler) Date: Fri, 15 Apr 2016 10:50:32 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <20160415084156.GO56633@Space.Net> References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> <20160415084156.GO56633@Space.Net> Message-ID: <20160415085032.GF25856@gir.theapt.org> On 2016 Apr 15 (Fri) at 10:41:56 +0200 (+0200), Gert Doering wrote: :Hi, : :On Thu, Apr 14, 2016 at 05:23:11PM +0100, Aled Morris wrote: :> The other objection (Jim) seems to be "we should be all-out promoting IPv6" :> which I think is a laudable goal but unfortunately when used against :> proposals like this one means that more recent LIRs are disadvantaged :> against established companies with large pools of IPv4 to fall back on. It :> simply isn't possible, today, to build an ISP on an IPv6-only proposition. : :Please do not forget the fact that small LIRs are not *disadvantaged* :by this policy, but actually *advantaged*. : :If we didn't have this policy, but just ran out like ARIN did, small :startup LIRs today would not be able to get *anything*. Now they can :get a /22. Is that enough? No. Can we fix it, without taking away :space that *other* small LIRs might want to have, in a few years time? : :Gert Doering : -- APWG chair This was exactly what happened to me at a previous job, and I am very happy that we were able to receive even a small-ish allocation of IPs. -- Hanson's Treatment of Time: There are never enough hours in a day, but always too many days before Saturday. From ripe at scholarwebservices.com Fri Apr 15 10:51:48 2016 From: ripe at scholarwebservices.com (ripe at scholarwebservices.com) Date: Fri, 15 Apr 2016 09:51:48 +0100 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <20160415081645.GE25856@gir.theapt.org> References: <570F9005.4090008@ripe.net> <20160414125115.GC25856@gir.theapt.org> <44515e0cc3a4bab757dbf0bab60999fe@gadago.net> <20160415081645.GE25856@gir.theapt.org> Message-ID: <0e50832d54204be518c4668303a7f1b1@gadago.net> Hi Peter, I do understand the argument of members not if favour of the proposal. We should all be adopting IPv6 and other means to overcome the problem and indeed the 185/8 should remain for new entrants as CGNAT etc. The reality is, we are still in a world where widespread IPv6 adoption is very slow. A single /22 is simply not enough for a new ISPs to grow and become competitive. Yes the marketplace is there, but most of us requiring additional IPv4 simply don't have the financial resource to make use of it at the current (frankly astronomical) rates. >From my understanding, the new proposal is to keep the 185/8 for new entrants as it was always intended, but allow returned addresses from IANA (currently in the region of a /9 to /10) to be reallocated. To me this is not unreasonable and what I am in favour of. Kind regard, Gavin On 2016-04-15 09:16, Peter Hessler wrote: > If you need/want more IPv4 addresses, the marketplace is available. > RIPE should not give more addresses to people that already have some. > > Growth into a market that should be killed, should not be encouraged by > RIPE. > > On 2016 Apr 14 (Thu) at 15:51:56 +0100 (+0100), ripe at scholarwebservices.com wrote: > : > : > :Hello, > : > :I am in favour of the proposal. Similar to Aled's comments below, we are > :a small entity that is restricted to growth with a single /22. I believe > :the 185/8 should be restricted to new entrants but allowing > :recycled/returned address space (outside of the 185/8) to be allocated, > :providing the LIR has less than a /20 in total. > : > :Kind regards, > : > :Gavin > : > :On 2016-04-14 15:34, Aled Morris wrote: > : > :> Peter, > :> > :> I agree with the proposal because it makes it possible for recent entrants into the market to grow. Speaking on behalf of such an entity, it's difficult to grow when you're limited to your one /22 in today's market. We (as an industry) are not there with IPv6 for this to be the only option. > :> > :> Ring-fencing 185/8 for new LIRs is sensible, this policy is really about recycling returned addresses and solves a real problem for a lot of recent new entrants. > :> > :> Of course we are all working on introducing IPv6 but I think we need this policy as it complements the allocation from 185/8 for new LIRs with a fair mechanism for nurturing LIRs who have filled their initial allocation. > :> > :> Aled > :> > :> On 14 April 2016 at 13:51, Peter Hessler wrote: > :> > :>> While I appreciate that there are more restricions on who is eligable to > :>> receive new allocations, I am still opposed to this proposal for the > :>> simple reason of "it depletes the IPv4 pool faster, and causes problems > :>> for new entrants". > :>> > :>> -- > :>> Anybody can win, unless there happens to be a second entry. > : -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian at idsys.ro Fri Apr 15 11:02:11 2016 From: adrian at idsys.ro (Adrian Pitulac) Date: Fri, 15 Apr 2016 12:02:11 +0300 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <20160415084156.GO56633@Space.Net> References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> <20160415084156.GO56633@Space.Net> Message-ID: <5710AE13.8060201@idsys.ro> Hi, First I personally support this policy because I believe the small LIR need help and not the larger ones, which stay relaxed on large pools and disagree with this policy because if small LIR grow, they will lose market share. It's easy for someone who administers a /16 or larger to disagree because its business won't stop to grow at the rate of a small LIR with a /22 or similar. What I'm talking about here is large pool -> more dynamic allocation/dis-allocation which translated in run the business at a certain level even if ipv4 pool is gone, where small pool results in stalled business growth for small LIR's. So even if you say the small LIR's are *advantaged* this won't hurt the market. The discussion regarding the last /8 policy benefit can be long, but from statistics and from my point of view, ARIN depletion of pools, resulted directly in IPV6 growth. Everyone talks about why RIPE IPv6 hasn't exploded. I think the reason is IPv4 pools still available. If market will be constrained by lack of IPv4 pools then IPv6 will explode. Also you should take into consideration that in the last 2 years, LIR number growth has been also due to large LIR's selling their pools and this generated a lot of the new LIR's to appear. I don't think we would see the same LIR number growth in the next 2 years. So we should plan accordingly and think about helping LIR's when needed. With regards, Adrian Pitulac On 15/04/16 11:41, Gert Doering wrote: > Hi, > > On Thu, Apr 14, 2016 at 05:23:11PM +0100, Aled Morris wrote: >> The other objection (Jim) seems to be "we should be all-out promoting IPv6" >> which I think is a laudable goal but unfortunately when used against >> proposals like this one means that more recent LIRs are disadvantaged >> against established companies with large pools of IPv4 to fall back on. It >> simply isn't possible, today, to build an ISP on an IPv6-only proposition. > Please do not forget the fact that small LIRs are not *disadvantaged* > by this policy, but actually *advantaged*. > > If we didn't have this policy, but just ran out like ARIN did, small > startup LIRs today would not be able to get *anything*. Now they can > get a /22. Is that enough? No. Can we fix it, without taking away > space that *other* small LIRs might want to have, in a few years time? > > Gert Doering > -- APWG chair From registry at tdc.se Fri Apr 15 11:14:24 2016 From: registry at tdc.se (registry at tdc.se) Date: Fri, 15 Apr 2016 09:14:24 +0000 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <5710AE13.8060201@idsys.ro> References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> Message-ID: Hi, I do not think anyone is disadvantaged. The fact is that we have talked about IPv4 exhaustion for years now. If you are thinking about starting a new LIR, please think first, as always when starting new business. Is it enough for your organization to have a /22 or not. Bigger LIR:s had several years to implement IPv6, the IPv4 exhaustion is nothing new. Of course, everyone want to apply for new addresses if possible to get them. But when the parcel with IPv4 addresses are empty, then it is empty. Julianna -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Adrian Pitulac Sent: den 15 april 2016 11:02 To: Gert Doering; Aled Morris Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) Hi, First I personally support this policy because I believe the small LIR need help and not the larger ones, which stay relaxed on large pools and disagree with this policy because if small LIR grow, they will lose market share. It's easy for someone who administers a /16 or larger to disagree because its business won't stop to grow at the rate of a small LIR with a /22 or similar. What I'm talking about here is large pool -> more dynamic allocation/dis-allocation which translated in run the business at a certain level even if ipv4 pool is gone, where small pool results in stalled business growth for small LIR's. So even if you say the small LIR's are *advantaged* this won't hurt the market. The discussion regarding the last /8 policy benefit can be long, but from statistics and from my point of view, ARIN depletion of pools, resulted directly in IPV6 growth. Everyone talks about why RIPE IPv6 hasn't exploded. I think the reason is IPv4 pools still available. If market will be constrained by lack of IPv4 pools then IPv6 will explode. Also you should take into consideration that in the last 2 years, LIR number growth has been also due to large LIR's selling their pools and this generated a lot of the new LIR's to appear. I don't think we would see the same LIR number growth in the next 2 years. So we should plan accordingly and think about helping LIR's when needed. With regards, Adrian Pitulac On 15/04/16 11:41, Gert Doering wrote: > Hi, > > On Thu, Apr 14, 2016 at 05:23:11PM +0100, Aled Morris wrote: >> The other objection (Jim) seems to be "we should be all-out promoting IPv6" >> which I think is a laudable goal but unfortunately when used against >> proposals like this one means that more recent LIRs are disadvantaged >> against established companies with large pools of IPv4 to fall back >> on. It simply isn't possible, today, to build an ISP on an IPv6-only proposition. > Please do not forget the fact that small LIRs are not *disadvantaged* > by this policy, but actually *advantaged*. > > If we didn't have this policy, but just ran out like ARIN did, small > startup LIRs today would not be able to get *anything*. Now they can > get a /22. Is that enough? No. Can we fix it, without taking away > space that *other* small LIRs might want to have, in a few years time? > > Gert Doering > -- APWG chair From tjc at ecs.soton.ac.uk Fri Apr 15 11:21:10 2016 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Fri, 15 Apr 2016 10:21:10 +0100 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <5710AE13.8060201@idsys.ro> References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <4DF65647-8E27-4B62-805A-BFBB79C3B895@ecs.soton.ac.uk> Message-ID: > On 15 Apr 2016, at 10:02, Adrian Pitulac wrote: > > but from statistics and from my point of view, ARIN depletion of pools, resulted directly in IPV6 growth. Well, no, not if you look at https://www.google.com/intl/en/ipv6/statistics.html, which shows steady IPv6 growth towards Google services (approaching 11% now). Similarly wrt active IPv6 routes - http://bgp.potaroo.net/v6/as2.0/index.html What statistics are you referring to? The policy in the RIPE region means that effectively we?ll ?never? run out, but that any new LIR can get a /22 to support public-facing services and some amount of CGNAT. In the ARIN region, they?re on the very last fumes of v4 address space as they had no such policy. > Everyone talks about why RIPE IPv6 hasn't exploded. I think the reason is IPv4 pools still available. If market will be constrained by lack of IPv4 pools then IPv6 will explode. The smart people are already well into their deployment programmes. But those take time. Comcast were one of the the first, and have benefitted from that. In the UK, Sky?s rollout has resumed, but has been a long-term project where, I believe, they decided that investing in IPv6 was much smarter than investing in bigger CGNATs. > Also you should take into consideration that in the last 2 years, LIR number growth has been also due to large LIR's selling their pools and this generated a lot of the new LIR's to appear. > I don't think we would see the same LIR number growth in the next 2 years. So we should plan accordingly and think about helping LIR's when needed. The RIPE NCC has done a great job in putting out information for several years, and encouraging adoption since at least 2011 - https://www.ripe.net/publications/ipv6-info-centre - so the help on IPv6 has been there for the taking... Tim > With regards, > Adrian Pitulac > > > On 15/04/16 11:41, Gert Doering wrote: >> Hi, >> >> On Thu, Apr 14, 2016 at 05:23:11PM +0100, Aled Morris wrote: >>> The other objection (Jim) seems to be "we should be all-out promoting IPv6" >>> which I think is a laudable goal but unfortunately when used against >>> proposals like this one means that more recent LIRs are disadvantaged >>> against established companies with large pools of IPv4 to fall back on. It >>> simply isn't possible, today, to build an ISP on an IPv6-only proposition. >> Please do not forget the fact that small LIRs are not *disadvantaged* >> by this policy, but actually *advantaged*. >> >> If we didn't have this policy, but just ran out like ARIN did, small >> startup LIRs today would not be able to get *anything*. Now they can >> get a /22. Is that enough? No. Can we fix it, without taking away >> space that *other* small LIRs might want to have, in a few years time? >> >> Gert Doering >> -- APWG chair > > > From robert.sleigh at ee.co.uk Fri Apr 15 13:37:37 2016 From: robert.sleigh at ee.co.uk (Sleigh, Robert) Date: Fri, 15 Apr 2016 11:37:37 +0000 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <570F9005.4090008@ripe.net> <20160414125115.GC25856@gir.theapt.org> Message-ID: <679694A32AB94046931C676BEF4BA8B8511D5C41@UK30S005EXS05.EEAD.EEINT.CO.UK> I agree with Jim's and many other people's later comments - we should prioritise keeping what's left of the IPv4 address space for the long term new entrants, not find ways to hand it out sooner to existing LIR's, large or small. For absolute clarity, I do not support this proposal Regards Bob 07958 318592 -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Jim Reid Sent: 14 April 2016 17:02 To: Aled Morris Cc: RIPE Address Policy WG Subject: Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) > On 14 Apr 2016, at 15:34, Aled Morris wrote: > > I agree with the proposal because it makes it possible for recent entrants into the market to grow. I strongly disagree with the proposal because it will encourage LIRs to fritter away scarce IPv4 resources which need to be conserved so there will be at least some IPv4 space available for new entrants 10? 20? 30? years from now. LIRs who take advantage of this proposal would continue to fail to deal with the v4 run-out. That would be bad for everyone. > Speaking on behalf of such an entity, it's difficult to grow when you're limited to your one /22 in today's market. Tough. It?s difficult to get on a train long after it has left the station. New entrants presumably know what the current v4 allocation policy is and should plan accordingly. Everyone would like to grow their IPv4 networks but that just isn?t possible any more. > We (as an industry) are not there with IPv6 for this to be the only option. It's the only sane option. But there are others. Choose wisely. Changing address policy to speed up depletion of the NCC's last dregs of IPv4 is not wise. Doing that just because some LIRs -- not necessarily new entrants -- can?t or won?t face up to the reality of IPv4 exhaustion is even more unwise. This proposal, if adopted, would be also unfair on the LIRs who *already have* taken action to deal with the v4 run-out. That can?t possibly be right. > Ring-fencing 185/8 for new LIRs is sensible, this policy is really about recycling returned addresses and solves a real problem for a lot of recent new entrants. I?m far from convinced there is a ?real problem? here. If compelling arguments can be made to define the problem and solve it, let?s hear them! IMO this proposal is really about short-term gain for some at the expense of others, particularly tomorrow?s new LIRs. BTW what?s to stop an unscrupulous LIR from repeatedly requesting extra /22s (or whatever) through this proposal and then selling/transferring the space without updating the database? If they tried to do this today, they could only get away with it once because they?d only get one v4 allocation. NOTICE AND DISCLAIMER This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. EE Limited Registered office:Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9BW Registered in England no: 02382161 EE Limited is a wholly owned subsidiary of: British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 From adrian at idsys.ro Fri Apr 15 15:33:33 2016 From: adrian at idsys.ro (Adrian Pitulac) Date: Fri, 15 Apr 2016 16:33:33 +0300 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <4DF65647-8E27-4B62-805A-BFBB79C3B895@ecs.soton.ac.uk> Message-ID: <5710EDAD.2000406@idsys.ro> I'm talking about the statistics presented even at RIPE 71 in Bucharest last year, where IPv6 capability in US grew 5% between 05.2015 and 11.2015. Coming back to the policy discussion, I don't see why keeping 185/8 for new entrants wouldn't be a viable solution. It's the exact thing which was intended when the last /8 policy was created. On 15/04/16 12:21, Tim Chown wrote: >> On 15 Apr 2016, at 10:02, Adrian Pitulac wrote: >> >> but from statistics and from my point of view, ARIN depletion of pools, resulted directly in IPV6 growth. > Well, no, not if you look at https://www.google.com/intl/en/ipv6/statistics.html, which shows steady IPv6 growth towards Google services (approaching 11% now). > > Similarly wrt active IPv6 routes - http://bgp.potaroo.net/v6/as2.0/index.html > > What statistics are you referring to? > > The policy in the RIPE region means that effectively we?ll ?never? run out, but that any new LIR can get a /22 to support public-facing services and some amount of CGNAT. In the ARIN region, they?re on the very last fumes of v4 address space as they had no such policy. > >> Everyone talks about why RIPE IPv6 hasn't exploded. I think the reason is IPv4 pools still available. If market will be constrained by lack of IPv4 pools then IPv6 will explode. > The smart people are already well into their deployment programmes. But those take time. Comcast were one of the the first, and have benefitted from that. In the UK, Sky?s rollout has resumed, but has been a long-term project where, I believe, they decided that investing in IPv6 was much smarter than investing in bigger CGNATs. > >> Also you should take into consideration that in the last 2 years, LIR number growth has been also due to large LIR's selling their pools and this generated a lot of the new LIR's to appear. >> I don't think we would see the same LIR number growth in the next 2 years. So we should plan accordingly and think about helping LIR's when needed. > The RIPE NCC has done a great job in putting out information for several years, and encouraging adoption since at least 2011 - https://www.ripe.net/publications/ipv6-info-centre - so the help on IPv6 has been there for the taking... > > Tim > >> With regards, >> Adrian Pitulac >> >> >> On 15/04/16 11:41, Gert Doering wrote: >>> Hi, >>> >>> On Thu, Apr 14, 2016 at 05:23:11PM +0100, Aled Morris wrote: >>>> The other objection (Jim) seems to be "we should be all-out promoting IPv6" >>>> which I think is a laudable goal but unfortunately when used against >>>> proposals like this one means that more recent LIRs are disadvantaged >>>> against established companies with large pools of IPv4 to fall back on. It >>>> simply isn't possible, today, to build an ISP on an IPv6-only proposition. >>> Please do not forget the fact that small LIRs are not *disadvantaged* >>> by this policy, but actually *advantaged*. >>> >>> If we didn't have this policy, but just ran out like ARIN did, small >>> startup LIRs today would not be able to get *anything*. Now they can >>> get a /22. Is that enough? No. Can we fix it, without taking away >>> space that *other* small LIRs might want to have, in a few years time? >>> >>> Gert Doering >>> -- APWG chair >> >> From tjc at ecs.soton.ac.uk Fri Apr 15 16:09:03 2016 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Fri, 15 Apr 2016 15:09:03 +0100 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <5710EDAD.2000406@idsys.ro> References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <4DF65647-8E27-4B62-805A-BFBB79C3B895@ecs.soton.ac.uk> <5710EDAD.2000406@idsys.ro> Message-ID: On 15 Apr 2016, at 14:33, Adrian Pitulac wrote: > > I'm talking about the statistics presented even at RIPE 71 in Bucharest last year, where IPv6 capability in US grew 5% between 05.2015 and 11.2015. It depends on your view. The Akamai stats at http://www.worldipv6launch.org/measurements/ suggest 2% increase over the same period, and linear growth that has flattened out a little. I suspect you mean slide 37 of https://ripe71.ripe.net/wp-content/uploads/presentations/56-RIPE71-bucharest-v6.pdf, which shows linear/slowing growth over that period, from a high starting point. I don?t think that slide supports your argument at all, and in any event any significant deployment takes time, you can?t just magic it up when an event happens. And regardless of 2% or 5%, that growth is a mix of residential operators like Comcast, who were deploying anyway during that period, and the mobile operators (T-Mobile, ATT, VeriZon, etc), who were *already* going v6-only to the handsets with NAT64/464XLAT for legacy v4. The US is now at around 25% overall, according to Google, or 17% according to Akamai. Interesting how much those numbers vary. > Coming back to the policy discussion, I don't see why keeping 185/8 for new entrants wouldn't be a viable solution. It's the exact thing which was intended when the last /8 policy was created. As others have said, everyone wants to grow. If you?re starting a new venture v6 should be at the heart of what you?re doing. Tim > On 15/04/16 12:21, Tim Chown wrote: >>> On 15 Apr 2016, at 10:02, Adrian Pitulac wrote: >>> >>> but from statistics and from my point of view, ARIN depletion of pools, resulted directly in IPV6 growth. >> Well, no, not if you look at https://www.google.com/intl/en/ipv6/statistics.html, which shows steady IPv6 growth towards Google services (approaching 11% now). >> >> Similarly wrt active IPv6 routes - http://bgp.potaroo.net/v6/as2.0/index.html >> >> What statistics are you referring to? >> >> The policy in the RIPE region means that effectively we?ll ?never? run out, but that any new LIR can get a /22 to support public-facing services and some amount of CGNAT. In the ARIN region, they?re on the very last fumes of v4 address space as they had no such policy. >> >>> Everyone talks about why RIPE IPv6 hasn't exploded. I think the reason is IPv4 pools still available. If market will be constrained by lack of IPv4 pools then IPv6 will explode. >> The smart people are already well into their deployment programmes. But those take time. Comcast were one of the the first, and have benefitted from that. In the UK, Sky?s rollout has resumed, but has been a long-term project where, I believe, they decided that investing in IPv6 was much smarter than investing in bigger CGNATs. >> >>> Also you should take into consideration that in the last 2 years, LIR number growth has been also due to large LIR's selling their pools and this generated a lot of the new LIR's to appear. >>> I don't think we would see the same LIR number growth in the next 2 years. So we should plan accordingly and think about helping LIR's when needed. >> The RIPE NCC has done a great job in putting out information for several years, and encouraging adoption since at least 2011 - https://www.ripe.net/publications/ipv6-info-centre - so the help on IPv6 has been there for the taking... >> >> Tim >> >>> With regards, >>> Adrian Pitulac >>> >>> >>> On 15/04/16 11:41, Gert Doering wrote: >>>> Hi, >>>> >>>> On Thu, Apr 14, 2016 at 05:23:11PM +0100, Aled Morris wrote: >>>>> The other objection (Jim) seems to be "we should be all-out promoting IPv6" >>>>> which I think is a laudable goal but unfortunately when used against >>>>> proposals like this one means that more recent LIRs are disadvantaged >>>>> against established companies with large pools of IPv4 to fall back on. It >>>>> simply isn't possible, today, to build an ISP on an IPv6-only proposition. >>>> Please do not forget the fact that small LIRs are not *disadvantaged* >>>> by this policy, but actually *advantaged*. >>>> >>>> If we didn't have this policy, but just ran out like ARIN did, small >>>> startup LIRs today would not be able to get *anything*. Now they can >>>> get a /22. Is that enough? No. Can we fix it, without taking away >>>> space that *other* small LIRs might want to have, in a few years time? >>>> >>>> Gert Doering >>>> -- APWG chair >>> >>> > > From adrian at idsys.ro Fri Apr 15 18:33:42 2016 From: adrian at idsys.ro (Adrian Pitulac) Date: Fri, 15 Apr 2016 19:33:42 +0300 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <4DF65647-8E27-4B62-805A-BFBB79C3B895@ecs.soton.ac.uk> <5710EDAD.2000406@idsys.ro> Message-ID: <571117E6.6050907@idsys.ro> Yes. That's the slide I was talking about. I did see something else, somewhere regarding to US IPv6 capability growth also, but I can't remember where right now. It was an entire article. At our company we have implemented IPv6 for 2 years now, and we have made a lot of lobby with our upstream providers at that time to have them support IPv6. I am seeing things also from another viewpoint when I'm asking our customers to implement IPv6 capabilities in their infrastructures, and they are replying that if there are still IPv4 resources available they are not yet interested in investing time and money into this transition. Even if I might appear strange, my personal opinion is that allowing IPv4 transfers created the possibility to prolong for a lot of time the IPv4 life. This also means that IPv6 growth will lag for a long time also based on this decision. Now keeping resources which might prolong IPv4 life again, is another bad thing. Our common interest is that IPv6 reaches the point where it will become the main protocol, so why not think about all the ways to get there as soon as possible. I am looking for anyone who rejects this policy, to provide a *statistic trend *for the period of time allocations will still be possible from the 185/8 for new LIR's, while the IANA blocks be reallocated to existing *small* LIR's. Also a realistic forecast for new LIR's number in the upcoming 1-2-3 years, would be very nice to see and to correlate with my previous statement. As I have told before my personal opinion is that the new LIR number will slowly decrease comparative to 2014/2015. With regards, Adrian Pitulac On 15/04/16 17:09, Tim Chown wrote: > On 15 Apr 2016, at 14:33, Adrian Pitulac wrote: >> I'm talking about the statistics presented even at RIPE 71 in Bucharest last year, where IPv6 capability in US grew 5% between 05.2015 and 11.2015. > It depends on your view. The Akamai stats at http://www.worldipv6launch.org/measurements/ suggest 2% increase over the same period, and linear growth that has flattened out a little. > > I suspect you mean slide 37 of https://ripe71.ripe.net/wp-content/uploads/presentations/56-RIPE71-bucharest-v6.pdf, which shows linear/slowing growth over that period, from a high starting point. I don?t think that slide supports your argument at all, and in any event any significant deployment takes time, you can?t just magic it up when an event happens. > > And regardless of 2% or 5%, that growth is a mix of residential operators like Comcast, who were deploying anyway during that period, and the mobile operators (T-Mobile, ATT, VeriZon, etc), who were *already* going v6-only to the handsets with NAT64/464XLAT for legacy v4. The US is now at around 25% overall, according to Google, or 17% according to Akamai. Interesting how much those numbers vary. > >> Coming back to the policy discussion, I don't see why keeping 185/8 for new entrants wouldn't be a viable solution. It's the exact thing which was intended when the last /8 policy was created. > As others have said, everyone wants to grow. If you?re starting a new venture v6 should be at the heart of what you?re doing. > > Tim > >> On 15/04/16 12:21, Tim Chown wrote: >>>> On 15 Apr 2016, at 10:02, Adrian Pitulac wrote: >>>> >>>> but from statistics and from my point of view, ARIN depletion of pools, resulted directly in IPV6 growth. >>> Well, no, not if you look at https://www.google.com/intl/en/ipv6/statistics.html, which shows steady IPv6 growth towards Google services (approaching 11% now). >>> >>> Similarly wrt active IPv6 routes - http://bgp.potaroo.net/v6/as2.0/index.html >>> >>> What statistics are you referring to? >>> >>> The policy in the RIPE region means that effectively we?ll ?never? run out, but that any new LIR can get a /22 to support public-facing services and some amount of CGNAT. In the ARIN region, they?re on the very last fumes of v4 address space as they had no such policy. >>> >>>> Everyone talks about why RIPE IPv6 hasn't exploded. I think the reason is IPv4 pools still available. If market will be constrained by lack of IPv4 pools then IPv6 will explode. >>> The smart people are already well into their deployment programmes. But those take time. Comcast were one of the the first, and have benefitted from that. In the UK, Sky?s rollout has resumed, but has been a long-term project where, I believe, they decided that investing in IPv6 was much smarter than investing in bigger CGNATs. >>> >>>> Also you should take into consideration that in the last 2 years, LIR number growth has been also due to large LIR's selling their pools and this generated a lot of the new LIR's to appear. >>>> I don't think we would see the same LIR number growth in the next 2 years. So we should plan accordingly and think about helping LIR's when needed. >>> The RIPE NCC has done a great job in putting out information for several years, and encouraging adoption since at least 2011 - https://www.ripe.net/publications/ipv6-info-centre - so the help on IPv6 has been there for the taking... >>> >>> Tim >>> >>>> With regards, >>>> Adrian Pitulac >>>> >>>> >>>> On 15/04/16 11:41, Gert Doering wrote: >>>>> Hi, >>>>> >>>>> On Thu, Apr 14, 2016 at 05:23:11PM +0100, Aled Morris wrote: >>>>>> The other objection (Jim) seems to be "we should be all-out promoting IPv6" >>>>>> which I think is a laudable goal but unfortunately when used against >>>>>> proposals like this one means that more recent LIRs are disadvantaged >>>>>> against established companies with large pools of IPv4 to fall back on. It >>>>>> simply isn't possible, today, to build an ISP on an IPv6-only proposition. >>>>> Please do not forget the fact that small LIRs are not *disadvantaged* >>>>> by this policy, but actually *advantaged*. >>>>> >>>>> If we didn't have this policy, but just ran out like ARIN did, small >>>>> startup LIRs today would not be able to get *anything*. Now they can >>>>> get a /22. Is that enough? No. Can we fix it, without taking away >>>>> space that *other* small LIRs might want to have, in a few years time? >>>>> >>>>> Gert Doering >>>>> -- APWG chair >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.petrov at i-net.bg Fri Apr 15 19:27:00 2016 From: m.petrov at i-net.bg (Momchil Petrov) Date: Fri, 15 Apr 2016 20:27:00 +0300 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <571117E6.6050907@idsys.ro> References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <4DF65647-8E27-4B62-805A-BFBB79C3B895@ecs.soton.ac.uk> <5710EDAD.2000406@idsys.ro> <571117E6.6050907@idsys.ro> Message-ID: <57112464.7020103@i-net.bg> Dear colleagues, is there anyone of you who will vote against that proposal can explain following: Big LIRs (mean with a lot of v4) provide to small ISPs internet+v4 ranges, now, how it is possible the new-LIR with only /22 do the same, i know - no way. In other way the small-ISP can become a LIR, this will continue exhaustion of the last /8 for sure. The situation seems to me big-LIR don't allow new-LIR to grow up... is this cartel or something Cheers, Momchil On 15.4.2016 ?. 19:33 ?., Adrian Pitulac wrote: > Yes. That's the slide I was talking about. I did see something else, > somewhere regarding to US IPv6 capability growth also, but I can't > remember where right now. It was an entire article. > > At our company we have implemented IPv6 for 2 years now, and we have > made a lot of lobby with our upstream providers at that time to have > them support IPv6. > > I am seeing things also from another viewpoint when I'm asking our > customers to implement IPv6 capabilities in their infrastructures, and > they are replying that if there are still IPv4 resources available > they are not yet interested in investing time and money into this > transition. > > Even if I might appear strange, my personal opinion is that allowing > IPv4 transfers created the possibility to prolong for a lot of time > the IPv4 life. This also means that IPv6 growth will lag for a long > time also based on this decision. > Now keeping resources which might prolong IPv4 life again, is another > bad thing. > > Our common interest is that IPv6 reaches the point where it will > become the main protocol, so why not think about all the ways to get > there as soon as possible. > > I am looking for anyone who rejects this policy, to provide a > *statistic trend *for the period of time allocations will still be > possible from the 185/8 for new LIR's, while the IANA blocks be > reallocated to existing *small* LIR's. > > Also a realistic forecast for new LIR's number in the upcoming 1-2-3 > years, would be very nice to see and to correlate with my previous > statement. As I have told before my personal opinion is that the new > LIR number will slowly decrease comparative to 2014/2015. > > With regards, > Adrian Pitulac > > On 15/04/16 17:09, Tim Chown wrote: >> On 15 Apr 2016, at 14:33, Adrian Pitulac wrote: >>> I'm talking about the statistics presented even at RIPE 71 in Bucharest last year, where IPv6 capability in US grew 5% between 05.2015 and 11.2015. >> It depends on your view. The Akamai stats athttp://www.worldipv6launch.org/measurements/ suggest 2% increase over the same period, and linear growth that has flattened out a little. >> >> I suspect you mean slide 37 ofhttps://ripe71.ripe.net/wp-content/uploads/presentations/56-RIPE71-bucharest-v6.pdf, which shows linear/slowing growth over that period, from a high starting point. I don?t think that slide supports your argument at all, and in any event any significant deployment takes time, you can?t just magic it up when an event happens. >> >> And regardless of 2% or 5%, that growth is a mix of residential operators like Comcast, who were deploying anyway during that period, and the mobile operators (T-Mobile, ATT, VeriZon, etc), who were *already* going v6-only to the handsets with NAT64/464XLAT for legacy v4. The US is now at around 25% overall, according to Google, or 17% according to Akamai. Interesting how much those numbers vary. >> >>> Coming back to the policy discussion, I don't see why keeping 185/8 for new entrants wouldn't be a viable solution. It's the exact thing which was intended when the last /8 policy was created. >> As others have said, everyone wants to grow. If you?re starting a new venture v6 should be at the heart of what you?re doing. >> >> Tim >> >>> On 15/04/16 12:21, Tim Chown wrote: >>>>> On 15 Apr 2016, at 10:02, Adrian Pitulac wrote: >>>>> >>>>> but from statistics and from my point of view, ARIN depletion of pools, resulted directly in IPV6 growth. >>>> Well, no, not if you look athttps://www.google.com/intl/en/ipv6/statistics.html, which shows steady IPv6 growth towards Google services (approaching 11% now). >>>> >>>> Similarly wrt active IPv6 routes -http://bgp.potaroo.net/v6/as2.0/index.html >>>> >>>> What statistics are you referring to? >>>> >>>> The policy in the RIPE region means that effectively we?ll ?never? run out, but that any new LIR can get a /22 to support public-facing services and some amount of CGNAT. In the ARIN region, they?re on the very last fumes of v4 address space as they had no such policy. >>>> >>>>> Everyone talks about why RIPE IPv6 hasn't exploded. I think the reason is IPv4 pools still available. If market will be constrained by lack of IPv4 pools then IPv6 will explode. >>>> The smart people are already well into their deployment programmes. But those take time. Comcast were one of the the first, and have benefitted from that. In the UK, Sky?s rollout has resumed, but has been a long-term project where, I believe, they decided that investing in IPv6 was much smarter than investing in bigger CGNATs. >>>> >>>>> Also you should take into consideration that in the last 2 years, LIR number growth has been also due to large LIR's selling their pools and this generated a lot of the new LIR's to appear. >>>>> I don't think we would see the same LIR number growth in the next 2 years. So we should plan accordingly and think about helping LIR's when needed. >>>> The RIPE NCC has done a great job in putting out information for several years, and encouraging adoption since at least 2011 -https://www.ripe.net/publications/ipv6-info-centre - so the help on IPv6 has been there for the taking... >>>> >>>> Tim >>>> >>>>> With regards, >>>>> Adrian Pitulac >>>>> >>>>> >>>>> On 15/04/16 11:41, Gert Doering wrote: >>>>>> Hi, >>>>>> >>>>>> On Thu, Apr 14, 2016 at 05:23:11PM +0100, Aled Morris wrote: >>>>>>> The other objection (Jim) seems to be "we should be all-out promoting IPv6" >>>>>>> which I think is a laudable goal but unfortunately when used against >>>>>>> proposals like this one means that more recent LIRs are disadvantaged >>>>>>> against established companies with large pools of IPv4 to fall back on. It >>>>>>> simply isn't possible, today, to build an ISP on an IPv6-only proposition. >>>>>> Please do not forget the fact that small LIRs are not *disadvantaged* >>>>>> by this policy, but actually *advantaged*. >>>>>> >>>>>> If we didn't have this policy, but just ran out like ARIN did, small >>>>>> startup LIRs today would not be able to get *anything*. Now they can >>>>>> get a /22. Is that enough? No. Can we fix it, without taking away >>>>>> space that *other* small LIRs might want to have, in a few years time? >>>>>> >>>>>> Gert Doering >>>>>> -- APWG chair > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe at liopen.fr Fri Apr 15 20:08:23 2016 From: ripe at liopen.fr (Denis Fondras) Date: Fri, 15 Apr 2016 20:08:23 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <57112464.7020103@i-net.bg> References: <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <4DF65647-8E27-4B62-805A-BFBB79C3B895@ecs.soton.ac.uk> <5710EDAD.2000406@idsys.ro> <571117E6.6050907@idsys.ro> <57112464.7020103@i-net.bg> Message-ID: <20160415180823.GB23516@jig-ai.ledeuns.net> > Big LIRs (mean with a lot of v4) provide to small ISPs internet+v4 ranges, > now, how it is possible the new-LIR with only /22 do the same, i know - no > way. > As there is no IPv4 available anymore for free, new-LIR can't become a big-LIR without big expenses (but with IPv6). That's a simple rule any new LIR can (and must) understand. If you read your LIR contract it is stated clearly you won't get more from RIPE. > In other way the small-ISP can become a LIR, this will continue exhaustion > of the last /8 for sure. > If "small-ISP" really wants to play the serious game, it should become LIR anyway. Denis From gert at space.net Fri Apr 15 20:23:59 2016 From: gert at space.net (Gert Doering) Date: Fri, 15 Apr 2016 20:23:59 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <57112464.7020103@i-net.bg> References: <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <4DF65647-8E27-4B62-805A-BFBB79C3B895@ecs.soton.ac.uk> <5710EDAD.2000406@idsys.ro> <571117E6.6050907@idsys.ro> <57112464.7020103@i-net.bg> Message-ID: <20160415182359.GA56633@Space.Net> Hi, On Fri, Apr 15, 2016 at 08:27:00PM +0300, Momchil Petrov wrote: > The situation seems to me big-LIR don't allow new-LIR to grow up... is > this cartel or something There is no way a "new-LIR" can grow to, say, a /12 level that some of the big and old Telcos have - which is unfortunate, but we did not make IPv4 with these short addresses. To the contrary: *because* the policy is so restrictive, "new-LIR" can have a business at all - if we had no last-/8 restrictions, RIPE NCC would have run out of addresses over a year ago, so "nothing at all" for new-LIRs. Which is more fair? (And we have this restrictive policy because the *old* LIRs restricted themselves(!) from eating up all the space, leaving something for the new LIRs to come) 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: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From adrian at idsys.ro Fri Apr 15 20:59:25 2016 From: adrian at idsys.ro (Adrian Pitulac) Date: Fri, 15 Apr 2016 21:59:25 +0300 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <20160415182359.GA56633@Space.Net> References: <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <4DF65647-8E27-4B62-805A-BFBB79C3B895@ecs.soton.ac.uk> <5710EDAD.2000406@idsys.ro> <571117E6.6050907@idsys.ro> <57112464.7020103@i-net.bg> <20160415182359.GA56633@Space.Net> Message-ID: <57113A0D.7020704@idsys.ro> Just two small comments.. Correct.. Having last /8 policy permits allowing new LIR to appear.. This is ok and can go on... Is there a reason why IANA blocks redistribution to existing small LIR's will restrict this /8 policy? I don't see it.. Imposing IPv6 deployment with this redistribution will just bring benefits. I'm a little doubtful that old LIR's restricted themselves from eating up all the space. I'm more inclining to believe that certain old LIR's made a big business from this, by creating an artificial market and then sold their free ip pools on the market for a hefty profit. Not to say about the greedy ones who destroyed small ISP's just to make profit from the ip ranges they had. With regards, Adrian Pitulac On 15/04/16 21:23, Gert Doering wrote: > Hi, > > On Fri, Apr 15, 2016 at 08:27:00PM +0300, Momchil Petrov wrote: >> The situation seems to me big-LIR don't allow new-LIR to grow up... is >> this cartel or something > There is no way a "new-LIR" can grow to, say, a /12 level that some of > the big and old Telcos have - which is unfortunate, but we did not make > IPv4 with these short addresses. > > To the contrary: *because* the policy is so restrictive, "new-LIR" can > have a business at all - if we had no last-/8 restrictions, RIPE NCC would > have run out of addresses over a year ago, so "nothing at all" for new-LIRs. > > Which is more fair? > > (And we have this restrictive policy because the *old* LIRs restricted > themselves(!) from eating up all the space, leaving something for the > new LIRs to come) > > Gert Doering > -- APWG chair From sebastian at karotte.org Fri Apr 15 22:12:31 2016 From: sebastian at karotte.org (Sebastian Wiesinger) Date: Fri, 15 Apr 2016 22:12:31 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <570F9005.4090008@ripe.net> References: <570F9005.4090008@ripe.net> Message-ID: <20160415201231.GA31001@danton.fire-world.de> * Marco Schmidt [2016-04-14 14:45]: > Dear colleagues, > > The Discussion Period for the policy proposal 2015-05, "Last /8 Allocation > Criteria Revision" has been extended until 13 May 2016. > > The goal of this proposal is to allow LIRs to request an additional /22 IPv4 > allocation from the RIPE NCC every 18 months. Hello, oppose this proposal. As others have already stated, the goal of the reserved pool is to enable new entrants into the IPv4 market while we're cleaning up the mess we made by not migrating to IPv6 sooner. Giving additional allocations to members will not further that goal. 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: 581 bytes Desc: Digital signature URL: From sebastian at karotte.org Fri Apr 15 22:33:27 2016 From: sebastian at karotte.org (Sebastian Wiesinger) Date: Fri, 15 Apr 2016 22:33:27 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <57113A0D.7020704@idsys.ro> References: <5710AE13.8060201@idsys.ro> <4DF65647-8E27-4B62-805A-BFBB79C3B895@ecs.soton.ac.uk> <5710EDAD.2000406@idsys.ro> <571117E6.6050907@idsys.ro> <57112464.7020103@i-net.bg> <20160415182359.GA56633@Space.Net> <57113A0D.7020704@idsys.ro> Message-ID: <20160415203327.GB31001@danton.fire-world.de> * Adrian Pitulac [2016-04-15 21:03]: > I'm a little doubtful that old LIR's restricted themselves from eating up > all the space. I'm more inclining to believe that certain old LIR's made a > big business from this, by creating an artificial market and then sold their > free ip pools on the market for a hefty profit. Not to say about the greedy > ones who destroyed small ISP's just to make profit from the ip ranges they > had. If we didn't have the policy the pool would be gone now and new LIRs would be forced to buy addresses on the free market. Don't you think that would've been the goal if "old" LIRs wanted to make money by selling their addresses? Most bigger LIRs make money by connecting people to the internet, believe it or not. The motivation to make money by selling address blocks only started a while ago and by my observation it's not primarily the old LIRs trying to make money from it. 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: 581 bytes Desc: Digital signature URL: From randy at psg.com Sat Apr 16 02:15:10 2016 From: randy at psg.com (Randy Bush) Date: Sat, 16 Apr 2016 09:15:10 +0900 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <007301d196e9$9b28be20$d17a3a60$@a2b-internet.com> References: <570F9005.4090008@ripe.net> <571080B4.70101@wirem.net> <007301d196e9$9b28be20$d17a3a60$@a2b-internet.com> Message-ID: i seek co-authors for a policy to make the last /8 allocation a /24 randy From h.lu at anytimechinese.com Sat Apr 16 05:20:50 2016 From: h.lu at anytimechinese.com (h.lu at anytimechinese.com) Date: Sat, 16 Apr 2016 11:20:50 +0800 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <570F9005.4090008@ripe.net> <571080B4.70101@wirem.net> <007301d196e9$9b28be20$d17a3a60$@a2b-internet.com> Message-ID: <673CC3D0-1CB6-4BF3-9540-4918235EEE1E@anytimechinese.com> IPv4 price will be one day high enough that make sense opening more LIR than buy in the market. So I would say this reserve pool will not last as long as some people might thinks. My bet stating next year we will see a much faster depletion rate. So no thank you, we don't need a new policy to make it happen even faster. > On 16 Apr 2016, at 08:15, Randy Bush wrote: > > i seek co-authors for a policy to make the last /8 allocation a /24 > > randy > From h.lu at anytimechinese.com Sat Apr 16 05:27:19 2016 From: h.lu at anytimechinese.com (h.lu at anytimechinese.com) Date: Sat, 16 Apr 2016 11:27:19 +0800 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <20160415182359.GA56633@Space.Net> References: <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <4DF65647-8E27-4B62-805A-BFBB79C3B895@ecs.soton.ac.uk> <5710EDAD.2000406@idsys.ro> <571117E6.6050907@idsys.ro> <57112464.7020103@i-net.bg> <20160415182359.GA56633@Space.Net> Message-ID: <32C199DF-7759-429A-A20E-3FFEB7DE758E@anytimechinese.com> Hi > On 16 Apr 2016, at 02:23, Gert Doering wrote: > > Hi, > >> On Fri, Apr 15, 2016 at 08:27:00PM +0300, Momchil Petrov wrote: >> The situation seems to me big-LIR don't allow new-LIR to grow up... is >> this cartel or something > > There is no way a "new-LIR" can grow to, say, a /12 level that some of > the big and old Telcos have - which is unfortunate, but we did not make > IPv4 with these short addresses. > Let me add something, if you have a business need /12 and your business can not even raise 10m in cash, seriously, I think there is something wrong with it. So no, new people can still grow to whatever size they want, maybe 10-15% more investment than the "good old time", but anyone who have done investment would tell you in exchange for a successful business, 10-15% more is tolerateble. > To the contrary: *because* the policy is so restrictive, "new-LIR" can > have a business at all - if we had no last-/8 restrictions, RIPE NCC would > have run out of addresses over a year ago, so "nothing at all" for new-LIRs. > > Which is more fair? > > (And we have this restrictive policy because the *old* LIRs restricted > themselves(!) from eating up all the space, leaving something for the > new LIRs to come) > > 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 info at servereasy.it Sat Apr 16 09:40:19 2016 From: info at servereasy.it (Servereasy) Date: Sat, 16 Apr 2016 09:40:19 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <673CC3D0-1CB6-4BF3-9540-4918235EEE1E@anytimechinese.com> References: <570F9005.4090008@ripe.net> <571080B4.70101@wirem.net> <007301d196e9$9b28be20$d17a3a60$@a2b-internet.com> <673CC3D0-1CB6-4BF3-9540-4918235EEE1E@anytimechinese.com> Message-ID: <5711EC63.4010906@servereasy.it> This is already happening, since IPv4 price on the market is too high. Il 16/04/2016 05:20, h.lu at anytimechinese.com ha scritto: > IPv4 price will be one day high enough that make sense opening more LIR than buy in the market. -- Saverio Giuntini Servereasy di Giuntini Saverio Amministrazione e system manager From ripe-wgs at radu-adrian.feurdean.net Sat Apr 16 11:31:12 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Sat, 16 Apr 2016 11:31:12 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <570F9005.4090008@ripe.net> <20160414125115.GC25856@gir.theapt.org> Message-ID: <1460799072.3821422.580493209.17E86513@webmail.messagingengine.com> On Thu, Apr 14, 2016, at 18:01, Jim Reid wrote: > > I strongly disagree with the proposal because it will encourage LIRs to > fritter away scarce IPv4 resources which need to be conserved so there > will be at least some IPv4 space available for new entrants 10? 20? 30? > years from now. Unless massive amount of space is returned or we change the rules again, the free pool will not survive 10 years. And if the purpose is to last as long as possible, other changes are required (strict needs assesment, more restrictions, penalties for not respecting the conditions) > LIRs who take advantage of this proposal would continue to fail to deal > with the v4 run-out. Because they can't. You can deploy as much IPv6 as you want, there still are things that require IPv4 without CGN. If you can't provide it, you don't sell. > New entrants presumably know what the current v4 allocation policy is and > should plan accordingly. No, most of them don't. They barely understand what RIPE and RIPE NCC are. Then at some point they find out (few of them know already) that years ago some people could get more space than they ever needed, while right now you can't get more than half of the previous minimum even if you need. I can understand that everybody should switch to transfers market at some point, but with only a /22 you will have lots of troubles reaching that point. Cases where you can go directly from a /22 to transfers are more the exception than the rule. > It's the only sane option. But there are others. Choose wisely. In certains situations (read market segements) there are no other options. At least not today. > This proposal, if adopted, would be also unfair on the LIRs who *already > have* taken action to deal with the v4 run-out. That can?t possibly be right. Actually no. On the contrary, they may have some fresh air. The only case where they may be impacted is going to the market and purchasing a "large enough block" (usually more than a /22). > BTW what?s to stop an unscrupulous LIR from repeatedly requesting extra > /22s (or whatever) through this proposal and then selling/transferring > the space without updating the database? If they tried to do this today, Time ? On the other hand, I would say that someone accepting the purchase of a block not declared in the database has a real problem to solve. -- Radu-Adrian FEURDEAN fr.ccs From ripe-wgs at radu-adrian.feurdean.net Sat Apr 16 11:35:54 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Sat, 16 Apr 2016 11:35:54 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> Message-ID: <1460799354.3822242.580510353.7C9C8CE3@webmail.messagingengine.com> Hi, On Thu, Apr 14, 2016, at 18:17, Dickinson, Ian wrote: > I?m arguing against it because it is the wrong thing to do, full stop. We > have a working policy, and we should stick with it. I'm not sure everyone has the same view of "working". > Anyway, I?ve registered my objection ? I?m done with this unless the text > changes. Noted. From ripe-wgs at radu-adrian.feurdean.net Sat Apr 16 11:53:48 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Sat, 16 Apr 2016 11:53:48 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <570F9005.4090008@ripe.net> Message-ID: <1460800428.3827613.580514625.67039F0D@webmail.messagingengine.com> On Thu, Apr 14, 2016, at 19:24, Randy Bush wrote: > the purpose of the single last /8 allocation was to allow NEW ENTRY. The *single* "last /8" (185.0.0.0/8) is still reserved to what most people consider new entry. Further allocations would be from recovered space, which can also serve "new entry". Did you actually read the new text ? > pigs coming back to the trough every 18 months is not new anything. No, it's not. It'a actually commonplace in the other RIRs. -- Radu-Adrian FEURDEAN fr.ccs From ripe-wgs at radu-adrian.feurdean.net Sat Apr 16 12:12:01 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Sat, 16 Apr 2016 12:12:01 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <002301d19689$48432160$d8c96420$@a2b-internet.com> References: <570F9005.4090008@ripe.net> <002301d19689$48432160$d8c96420$@a2b-internet.com> Message-ID: <1460801521.3831934.580518673.0914BA5F@webmail.messagingengine.com> Hi Erik, On Thu, Apr 14, 2016, at 22:07, Erik Bais wrote: > If we currently have about 12.000 members .. and hand out additional > /22?s to each of them, it will cost 12 milj addresses ( more or less..) > ( as it would be more fair than discriminating on current size and age of > an LIR ? ) We won't "hand them out". We live them the choice to ask. Please note that some of them didn't request their /22 as per current policy. > The pool won?t grow much more than it is currently ? We are aware. > So handing out 12 milj. addresses in a single gift.. without the hard Again, we are not doing this in a "single gift". Or at least it is not what we wanted to say. > requirement to not allow final /8 policy received IP space to be > transferred, will most likely only increase the run-out of the IP space > and not fix anything.. This is something worth discussing. I think enough people were complaining about this in order to start discussing this more seriously. > If we hand out 12 milj. Addresses of the 16.4 milj. We have 4.4 milj. > addresses left.. meaning that we will have a full run-out within 18 > months. Then again, we are not talking about handing out in one shot ! Otherwise, I can understand your point of view. -- Radu-Adrian FEURDEAN fr.ccs From ripe-wgs at radu-adrian.feurdean.net Sat Apr 16 12:27:50 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Sat, 16 Apr 2016 12:27:50 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <571080B4.70101@wirem.net> References: <570F9005.4090008@ripe.net> <571080B4.70101@wirem.net> Message-ID: <1460802470.3835825.580528361.6FE98BD0@webmail.messagingengine.com> Hi, On Fri, Apr 15, 2016, at 07:48, Riccardo Gori wrote: > We are dealing with the same amount of space as September 2012 that in > the meanwhile has been abused in several ways and there are really no > incentives to IPv6 adoption. > > There was only one requirement to obtain one IPv4 /22: request and > obtain at least from /32 IPv6 to a maximum of /29 IPv6. > Am I wrong or this requirement has been removed?!?! Please explain that > to a new entrant... Not only that, but since 2014 IPv4 blocks are to be handed without any justification. Basically RIPE NCC sells IPv4 adresses. I would definitely NOT call that a success. > I think this policy is not for faster exhaustion but for "farier > exhaustion" and is offering a path to go over IPv4 while still needing > it to grow. What we are trying to compensante is the "fair" part which is diminishing with time. -- Radu-Adrian FEURDEAN fr.ccs From remco.vanmook at gmail.com Sat Apr 16 12:29:52 2016 From: remco.vanmook at gmail.com (=?utf-8?B?cmVtY28udmFubW9va0BnbWFpbC5jb20=?=) Date: Sat, 16 Apr 2016 12:29:52 +0200 Subject: [address-policy-wg] =?utf-8?q?2015-05_Discussion_Period_extended_?= =?utf-8?q?until_13_May_2016_=28Last_/8_Allocation_Criteria_Revision=29?= Message-ID: <57121420.6614c20a.ebfb5.4312@mx.google.com> This confusion has been haunting the final /8 policy from day one - it was never about what to do with specifically 185/8, but what to do with all future allocations from the moment we needed to start allocating out of it. The policy text itself was never limited to a single /8, nor was that limitation any part of the discussion. Remco Sent from my HTC ----- Reply message ----- From: "Radu-Adrian FEURDEAN" To: "Randy Bush" , "Marco Schmidt" Cc: "RIPE address policy WG" Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) Date: Sat, Apr 16, 2016 11:53 On Thu, Apr 14, 2016, at 19:24, Randy Bush wrote: > the purpose of the single last /8 allocation was to allow NEW ENTRY. The *single* "last /8" (185.0.0.0/8) is still reserved to what most people consider new entry. Further allocations would be from recovered space, which can also serve "new entry". Did you actually read the new text ? > pigs coming back to the trough every 18 months is not new anything. No, it's not. It'a actually commonplace in the other RIRs. -- Radu-Adrian FEURDEAN fr.ccs -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe-wgs at radu-adrian.feurdean.net Sat Apr 16 12:49:45 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Sat, 16 Apr 2016 12:49:45 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <20160415081645.GE25856@gir.theapt.org> References: <570F9005.4090008@ripe.net> <20160414125115.GC25856@gir.theapt.org> <44515e0cc3a4bab757dbf0bab60999fe@gadago.net> <20160415081645.GE25856@gir.theapt.org> Message-ID: <1460803785.3840375.580539225.0273B0E7@webmail.messagingengine.com> On Fri, Apr 15, 2016, at 10:16, Peter Hessler wrote: > Growth into a market that should be killed, should not be encouraged by RIPE. What you are actually saying is the "Internet Access for Small Business" market should be killed. A "softer" interpretation would be that it should be left to "big enough players". ... and there are other markets where "no dedicated IPv4 per customer" equals no business. From tom.smyth at wirelessconnect.eu Sat Apr 16 12:51:32 2016 From: tom.smyth at wirelessconnect.eu (Tom Smyth) Date: Sat, 16 Apr 2016 11:51:32 +0100 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <1460800428.3827613.580514625.67039F0D@webmail.messagingengine.com> References: <570F9005.4090008@ripe.net> <1460800428.3827613.580514625.67039F0D@webmail.messagingengine.com> Message-ID: I was in support of relaxing the allocation rules for existing lirs as long as the organisation that might benefit from extra IPs did transfer ( or Sell ) IP space previously allocated, to prevent further abuse. But I can see the principal of protecting Ip space for new entrants is much fairer and more sustainable than what would be a short sighted gain of 1024 addresses every 18 months..for existing Lirs, Im against this proposal ... i can see the benefit of having addresses for new entrants to the market.. No more flip flopping from me on this proposal Thanks... On Sat, Apr 16, 2016 at 10:53 AM, Radu-Adrian FEURDEAN < ripe-wgs at radu-adrian.feurdean.net> wrote: > On Thu, Apr 14, 2016, at 19:24, Randy Bush wrote: > > the purpose of the single last /8 allocation was to allow NEW ENTRY. > > The *single* "last /8" (185.0.0.0/8) is still reserved to what most > people consider new entry. > Further allocations would be from recovered space, which can also serve > "new entry". > Did you actually read the new text ? > > > pigs coming back to the trough every 18 months is not new anything. > > No, it's not. It'a actually commonplace in the other RIRs. > > -- > Radu-Adrian FEURDEAN > fr.ccs > > -- Kindest regards, Tom Smyth Mobile: +353 87 6193172 --------------------------------- PLEASE CONSIDER THE ENVIRONMENT BEFORE YOU PRINT THIS E-MAIL This email contains information which may be confidential or privileged. The information is intended solely for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify me by telephone or by electronic mail immediately. Any opinions expressed are those of the author, not the company's .This email does not constitute either offer or acceptance of any contractually binding agreement. Such offer or acceptance must be communicated in writing. You are requested to carry out your own virus check before opening any attachment. Thomas Smyth accepts no liability for any loss or damage which may be caused by malicious software or attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe-wgs at radu-adrian.feurdean.net Sat Apr 16 12:52:00 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Sat, 16 Apr 2016 12:52:00 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <570F9005.4090008@ripe.net> <571080B4.70101@wirem.net> Message-ID: <1460803920.3842448.580540425.075AC1CF@webmail.messagingengine.com> On Fri, Apr 15, 2016, at 10:33, Tim Chown wrote: > > there are really no incentives to IPv6 adoption. > > Really? What incentive ? A black T-Shirt ? (for the record, I preferred the blue one handed out ~2010-2012). From tom.smyth at wirelessconnect.eu Sat Apr 16 12:52:21 2016 From: tom.smyth at wirelessconnect.eu (Tom Smyth) Date: Sat, 16 Apr 2016 11:52:21 +0100 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <570F9005.4090008@ripe.net> <1460800428.3827613.580514625.67039F0D@webmail.messagingengine.com> Message-ID: sorry minor edit , major change > I was in support of relaxing the allocation rules for existing lirs as > long as the organisation that might benefit from extra IPs *did NOT* > transfer ( or Sell ) IP space previously allocated, to prevent further > abuse. > > But I can see the principal of protecting Ip space for new entrants is > much fairer and more sustainable than what would be a short sighted gain of > 1024 addresses every 18 months..for existing Lirs, > > Im against this proposal ... i can see the benefit of having addresses for > new entrants to the market.. > > No more flip flopping from me on this proposal > > Thanks... > > > On Sat, Apr 16, 2016 at 10:53 AM, Radu-Adrian FEURDEAN < > ripe-wgs at radu-adrian.feurdean.net> wrote: > >> On Thu, Apr 14, 2016, at 19:24, Randy Bush wrote: >> > the purpose of the single last /8 allocation was to allow NEW ENTRY. >> >> The *single* "last /8" (185.0.0.0/8) is still reserved to what most >> people consider new entry. >> Further allocations would be from recovered space, which can also serve >> "new entry". >> Did you actually read the new text ? >> >> > pigs coming back to the trough every 18 months is not new anything. >> >> No, it's not. It'a actually commonplace in the other RIRs. >> >> -- >> Radu-Adrian FEURDEAN >> fr.ccs >> >> > > > -- > Kindest regards, > Tom Smyth > > Mobile: +353 87 6193172 > --------------------------------- > PLEASE CONSIDER THE ENVIRONMENT BEFORE YOU PRINT THIS E-MAIL > This email contains information which may be confidential or privileged. > The information is intended solely for the use of the individual or entity > named above. If you are not the intended recipient, be aware that > any disclosure, copying, distribution or use of the contents of this > information is prohibited. If you have received this electronic > transmission in error, please notify me by telephone or by electronic mail > immediately. Any opinions expressed are those of the author, not the > company's .This email does not constitute either offer or acceptance of > any contractually binding agreement. Such offer or acceptance must be > communicated in > writing. You are requested to carry out your own virus check before > opening any attachment. Thomas Smyth accepts no liability for any loss or > damage which may be caused by malicious software or attachments. > -- Kindest regards, Tom Smyth Mobile: +353 87 6193172 --------------------------------- PLEASE CONSIDER THE ENVIRONMENT BEFORE YOU PRINT THIS E-MAIL This email contains information which may be confidential or privileged. The information is intended solely for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify me by telephone or by electronic mail immediately. Any opinions expressed are those of the author, not the company's .This email does not constitute either offer or acceptance of any contractually binding agreement. Such offer or acceptance must be communicated in writing. You are requested to carry out your own virus check before opening any attachment. Thomas Smyth accepts no liability for any loss or damage which may be caused by malicious software or attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at foobar.org Sat Apr 16 13:02:55 2016 From: nick at foobar.org (Nick Hilliard) Date: Sat, 16 Apr 2016 12:02:55 +0100 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <571080B4.70101@wirem.net> References: <570F9005.4090008@ripe.net> <571080B4.70101@wirem.net> Message-ID: <57121BDF.6020706@foobar.org> Riccardo Gori wrote: > I think this policy is not for faster exhaustion but for "farier > exhaustion" and is offering a path to go over IPv4 while still needing > it to grow. It was only a matter of time before someone pulled out the word "fair". "Fair" is a hugely subjective term best left to experts in the field: namely children below the age of 16, all of whom have extraordinary skills in the art of determining what is "fair", and more importantly, what is not. In order to make things better for one section of the RIPE community, another part of the community will need to pay the price. There are several ways of doing this: we could tilt the policy in favour of larger organisations at the cost of smaller organisations, or smaller organisations at the cost of larger organisations, or existing organisations in favour of future market entrants. Currently the ipv4 allocation policy gives precedence to future market entrants and smaller players. This is an unusually altruistic position, given that future market entrants have no say in how current policy is determined. 2015-05 will change this balance further in favour of smaller players at the expense of future market entrants. At a helicopter level and speaking as a smaller LIR, I don't believe that this is a good thing to do and consequently I do not support the policy change. Nick From ripe-wgs at radu-adrian.feurdean.net Sat Apr 16 13:03:15 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Sat, 16 Apr 2016 13:03:15 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <20160415084156.GO56633@Space.Net> References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> <20160415084156.GO56633@Space.Net> Message-ID: <1460804595.3844842.580541241.0AF188D7@webmail.messagingengine.com> On Fri, Apr 15, 2016, at 10:41, Gert Doering wrote: > If we didn't have this policy, but just ran out like ARIN did, small Gert, ARIN didn't run out dry (contrary to the popular behaviour). They barely entered some sort of "last /10" (23.128.0.0/10) , which is very restrictive. -- Radu-Adrian FEURDEAN fr.ccs From jim at rfc1035.com Sat Apr 16 13:21:37 2016 From: jim at rfc1035.com (Jim Reid) Date: Sat, 16 Apr 2016 12:21:37 +0100 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <1460799072.3821422.580493209.17E86513@webmail.messagingengine.com> References: <570F9005.4090008@ripe.net> <20160414125115.GC25856@gir.theapt.org> <1460799072.3821422.580493209.17E86513@webmail.messagingengine.com> Message-ID: <010AD9D5-E830-4A4B-B979-E0EC38A34B01@rfc1035.com> > On 16 Apr 2016, at 10:31, Radu-Adrian FEURDEAN wrote: > > On Thu, Apr 14, 2016, at 18:01, Jim Reid wrote: >> >> I strongly disagree with the proposal because it will encourage LIRs to >> fritter away scarce IPv4 resources which need to be conserved so there >> will be at least some IPv4 space available for new entrants 10? 20? 30? >> years from now. > > Unless massive amount of space is returned or we change the rules again, > the free pool will not survive 10 years. Maybe, maybe not. This proposal, if adopted, would pretty much guarantee the free pool would not survive 10 months. That is one of the reasons why I oppose it. > And if the purpose is to last as long as possible, other changes are > required (strict needs assesment, more restrictions, penalties for not > respecting the conditions) Feel free to submit policy proposals which make those chnges. :-) > Because they can't. You can deploy as much IPv6 as you want, there still > are things that require IPv4 without CGN. If you can't provide it, you > don't sell. Tough. When you?ve burnt though the free pool, you *still* won?t have the v4 space to do these things that can?t be done with NAT or whatever. What are you going to do then? And why can?t/won't you adopt these measures now? >> New entrants presumably know what the current v4 allocation policy is and >> should plan accordingly. > > No, most of them don?t. Well frankly, that?s their problem. Anyone building a network or setting up a business now which is predicated on a never-ending abundance of IPv4 simply hasn?t done their homework. I wish them luck. They?re going to need it. > They barely understand what RIPE and RIPE NCC > are. Then at some point they find out (few of them know already) that > years ago some people could get more space than they ever needed, while > right now you can't get more than half of the previous minimum even if > you need. So what? The rules and circumstances were different back then. Things change. Deal with it. > In certains situations (read market segements) there are no other > options. At least not today. Well frittering away the free pool is not an option. And even if it was, it could not solve the problems you appear to think this proposal would solve. We?re essentially out of IPv4. *Everyone* simply has to recognise that fact and take appropriate action. >> This proposal, if adopted, would be also unfair on the LIRs who *already >> have* taken action to deal with the v4 run-out. That can?t possibly be right. > > Actually no. On the contrary, they may have some fresh air. The only > case where they may be impacted is going to the market and purchasing a > "large enough block" (usually more than a /22). Nope. If I was an LIR who had deployed IPv6 or NAT or bought space because the NCC couldn?t give me more than 1 /22, I?d sue for damages if the policy was later changed to allow multiple /22s. I wouldn?t have had those deployment hassles and costs if the NCC had allocated me a few more /22s. A really angry LIR could go to court for Injunctive Relief and also get their government and regulators to intervene. I hope you agree we don?t want to adopt something which increases the risk of these unpleasantries happening. From ripe-wgs at radu-adrian.feurdean.net Sat Apr 16 13:24:06 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Sat, 16 Apr 2016 13:24:06 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <4DF65647-8E27-4B62-805A-BFBB79C3B895@ecs.soton.ac.uk> Message-ID: <1460805846.3849264.580550033.1B369948@webmail.messagingengine.com> On Fri, Apr 15, 2016, at 11:21, Tim Chown wrote: > > On 15 Apr 2016, at 10:02, Adrian Pitulac wrote: > > > > but from statistics and from my point of view, ARIN depletion of pools, resulted directly in IPV6 growth. > > Well, no, not if you look at > https://www.google.com/intl/en/ipv6/statistics.html, which shows steady > IPv6 growth towards Google services (approaching 11% now). That's global. For Canada : http://stats.labs.apnic.net/ipv6/CA that's clearly visible. Less so for the US. > Similarly wrt active IPv6 routes - > http://bgp.potaroo.net/v6/as2.0/index.html Route count, like allocations made by RIRs is completely irrelevant. Having IPv6 announced but null-routed at the border and completely absent inside the network (or only present on core equipment) is commonplace. From ripe-wgs at radu-adrian.feurdean.net Sat Apr 16 13:36:39 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Sat, 16 Apr 2016 13:36:39 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <4DF65647-8E27-4B62-805A-BFBB79C3B895@ecs.soton.ac.uk> <5710EDAD.2000406@idsys.ro> Message-ID: <1460806599.3851826.580556689.6B4BC0D8@webmail.messagingengine.com> On Fri, Apr 15, 2016, at 16:09, Tim Chown wrote: > As others have said, everyone wants to grow. If you?re starting a new > venture v6 should be at the heart of what you?re doing. Tim, This is a good way not to start a business, and if you still do it, not to have many customers. No matter how much you have IPv6 at heart, as of 16/04/2016 on most markets "no IPv4" = "no business". For some customers, they won't use IPv6 even if you bring it at their doorstep. Been there, done that, still doing that. From jim at rfc1035.com Sat Apr 16 13:36:53 2016 From: jim at rfc1035.com (Jim Reid) Date: Sat, 16 Apr 2016 12:36:53 +0100 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <1460803785.3840375.580539225.0273B0E7@webmail.messagingengine.com> References: <570F9005.4090008@ripe.net> <20160414125115.GC25856@gir.theapt.org> <44515e0cc3a4bab757dbf0bab60999fe@gadago.net> <20160415081645.GE25856@gir.theapt.org> <1460803785.3840375.580539225.0273B0E7@webmail.messagingengine.com> Message-ID: > On 16 Apr 2016, at 11:49, Radu-Adrian FEURDEAN wrote: > > ... and there are other markets where "no dedicated IPv4 per customer" > equals no business. And these other markets are either dead or dying because there is no more IPv4. Some might survive if they can adapt to reality in time. Any current business model which depends on issuing a dedicated (public?) IPv4 addresses to new customers is doomed. That model is simply not sustainable any more. Either change the model or go bust. Pick one. From rgori at wirem.net Sat Apr 16 13:37:13 2016 From: rgori at wirem.net (Riccardo Gori) Date: Sat, 16 Apr 2016 13:37:13 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <57121BDF.6020706@foobar.org> References: <570F9005.4090008@ripe.net> <571080B4.70101@wirem.net> <57121BDF.6020706@foobar.org> Message-ID: <571223E9.90606@wirem.net> Hi Nick, everyone is aware that fairness is a relative concept. What we mean in this proposal is that actual policy is encouraging transfer market in some way 'cause there is a transfert market to feed. Is someone asks for space because of need he won't sell outside the resource just to make quick bucks. This proposal aims to address the real need and give a little incentive (the only around are now t-shirts mentioned by Radu) to IPv6 regards Riccardo Il 16/04/2016 13:02, Nick Hilliard ha scritto: > Riccardo Gori wrote: >> I think this policy is not for faster exhaustion but for "farier >> exhaustion" and is offering a path to go over IPv4 while still needing >> it to grow. > It was only a matter of time before someone pulled out the word "fair". > > "Fair" is a hugely subjective term best left to experts in the field: > namely children below the age of 16, all of whom have extraordinary > skills in the art of determining what is "fair", and more importantly, > what is not. > > In order to make things better for one section of the RIPE community, > another part of the community will need to pay the price. There are > several ways of doing this: we could tilt the policy in favour of larger > organisations at the cost of smaller organisations, or smaller > organisations at the cost of larger organisations, or existing > organisations in favour of future market entrants. > > Currently the ipv4 allocation policy gives precedence to future market > entrants and smaller players. This is an unusually altruistic position, > given that future market entrants have no say in how current policy is > determined. > > 2015-05 will change this balance further in favour of smaller players at > the expense of future market entrants. > > At a helicopter level and speaking as a smaller LIR, I don't believe > that this is a good thing to do and consequently I do not support the > policy change. > > Nick -- Ing. Riccardo Gori e-mail: rgori at wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info at wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logoWirem_4cm_conR.jpg Type: image/jpeg Size: 41774 bytes Desc: not available URL: From adrian at idsys.ro Sat Apr 16 14:48:44 2016 From: adrian at idsys.ro (Adrian Pitulac) Date: Sat, 16 Apr 2016 15:48:44 +0300 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <010AD9D5-E830-4A4B-B979-E0EC38A34B01@rfc1035.com> References: <570F9005.4090008@ripe.net> <20160414125115.GC25856@gir.theapt.org> <1460799072.3821422.580493209.17E86513@webmail.messagingengine.com> <010AD9D5-E830-4A4B-B979-E0EC38A34B01@rfc1035.com> Message-ID: <571234AC.6070108@idsys.ro> >> >On 16 Apr 2016, at 10:31, Radu-Adrian FEURDEAN wrote: >> > >> >On Thu, Apr 14, 2016, at 18:01, Jim Reid wrote: >>> >> >>> >>I strongly disagree with the proposal because it will encourage LIRs to >>> >>fritter away scarce IPv4 resources which need to be conserved so there >>> >>will be at least some IPv4 space available for new entrants 10? 20? 30? >>> >>years from now. >> > >> >Unless massive amount of space is returned or we change the rules again, >> >the free pool will not survive 10 years. > Maybe, maybe not. > > This proposal, if adopted, would pretty much guarantee the free pool would not survive 10 months. That is one of the reasons why I oppose it. > How is this going to happen? Will the 185/8 going to being depleted by new LIRs in 10 months? I'm I missing something? Have you really read the policy change, or are you against any policy change by default? >>> This proposal, if adopted, would be also unfair on the LIRs who *already >>> >>have* taken action to deal with the v4 run-out. That can?t possibly be right. >> > >> >Actually no. On the contrary, they may have some fresh air. The only >> >case where they may be impacted is going to the market and purchasing a >> >"large enough block" (usually more than a /22). > Nope. If I was an LIR who had deployed IPv6 or NAT or bought space because the NCC couldn?t give me more than 1 /22, I?d sue for damages if the policy was later changed to allow multiple /22s. I wouldn?t have had those deployment hassles and costs if the NCC had allocated me a few more /22s. A really angry LIR could go to court for Injunctive Relief and also get their government and regulators to intervene. > > I hope you agree we don?t want to adopt something which increases the risk of these unpleasantries happening. > > I don't think this could happen, as policy's are similar to laws. If your government raises taxes next year you won't be able to sue them for that. So I think this kind of arguments have no real support. From info at servereasy.it Sat Apr 16 15:23:54 2016 From: info at servereasy.it (Servereasy) Date: Sat, 16 Apr 2016 15:23:54 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <571234AC.6070108@idsys.ro> References: <570F9005.4090008@ripe.net> <20160414125115.GC25856@gir.theapt.org> <1460799072.3821422.580493209.17E86513@webmail.messagingengine.com> <010AD9D5-E830-4A4B-B979-E0EC38A34B01@rfc1035.com> <571234AC.6070108@idsys.ro> Message-ID: <57123CEA.30505@servereasy.it> As we all know, there are lot of big LIRs with plenty of unused (or wasted) space, and now they are making serious business selling their classes. With a current price of about 10?/IP, it's easy to understand how big are interests behind this: some LIRs could make M? just by selling something they obtained for free some years ago. It's clear that we can't "generate" more IPv4, but IMHO this is totally against a fair market. A new LIR with just a /22 shouldn't be charged like one with tons of /12: if having lot of IPv4 would be anti-economical for big LIRs, this would be a *real* incentivation for IPv6 deployment and return of IPv4. I'm not a lawyer, but probabily this problem should be reviewd by European Commission for Competition. Br -- Saverio Giuntini Servereasy di Giuntini Saverio Amministrazione e system manager -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominik at clouvider.co.uk Sat Apr 16 15:53:45 2016 From: dominik at clouvider.co.uk (Dominik Nowacki) Date: Sat, 16 Apr 2016 13:53:45 +0000 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <010AD9D5-E830-4A4B-B979-E0EC38A34B01@rfc1035.com> References: <570F9005.4090008@ripe.net> <20160414125115.GC25856@gir.theapt.org> <1460799072.3821422.580493209.17E86513@webmail.messagingengine.com> <010AD9D5-E830-4A4B-B979-E0EC38A34B01@rfc1035.com> Message-ID: > Nope. If I was an LIR who had deployed IPv6 or NAT or bought space because the NCC couldn?t give me more than 1 /22, I?d sue for damages if the policy was later changed to allow multiple /22s. I wouldn?t have had those deployment hassles and costs if the NCC had allocated me a few more /22s. A really angry LIR could go to court for Injunctive Relief and also get their government and regulators to intervene. > I hope you agree we don?t want to adopt something which increases the risk of these unpleasantries happening. And such LIR would sue who? Himself? RIPE NCC is not a government body, nor a private company. It's an organisation of members, and such a LIR would have to be a member with set voting rights. You can't really sue for policy changes because you don't like how other, equal members voted. I'm not a lawyer but I don't see this stand in court. Missed argument. Kind Regards, Dom -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Jim Reid Sent: 16 April 2016 12:22 To: Radu-Adrian FEURDEAN Cc: RIPE Address Policy WG Subject: Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) > On 16 Apr 2016, at 10:31, Radu-Adrian FEURDEAN wrote: > > On Thu, Apr 14, 2016, at 18:01, Jim Reid wrote: >> >> I strongly disagree with the proposal because it will encourage LIRs >> to fritter away scarce IPv4 resources which need to be conserved so >> there will be at least some IPv4 space available for new entrants 10? 20? 30? >> years from now. > > Unless massive amount of space is returned or we change the rules > again, the free pool will not survive 10 years. Maybe, maybe not. This proposal, if adopted, would pretty much guarantee the free pool would not survive 10 months. That is one of the reasons why I oppose it. > And if the purpose is to last as long as possible, other changes are > required (strict needs assesment, more restrictions, penalties for not > respecting the conditions) Feel free to submit policy proposals which make those chnges. :-) > Because they can't. You can deploy as much IPv6 as you want, there > still are things that require IPv4 without CGN. If you can't provide > it, you don't sell. Tough. When you?ve burnt though the free pool, you *still* won?t have the v4 space to do these things that can?t be done with NAT or whatever. What are you going to do then? And why can?t/won't you adopt these measures now? >> New entrants presumably know what the current v4 allocation policy is >> and should plan accordingly. > > No, most of them don?t. Well frankly, that?s their problem. Anyone building a network or setting up a business now which is predicated on a never-ending abundance of IPv4 simply hasn?t done their homework. I wish them luck. They?re going to need it. > They barely understand what RIPE and RIPE NCC are. Then at some point > they find out (few of them know already) that years ago some people > could get more space than they ever needed, while right now you can't > get more than half of the previous minimum even if you need. So what? The rules and circumstances were different back then. Things change. Deal with it. > In certains situations (read market segements) there are no other > options. At least not today. Well frittering away the free pool is not an option. And even if it was, it could not solve the problems you appear to think this proposal would solve. We?re essentially out of IPv4. *Everyone* simply has to recognise that fact and take appropriate action. >> This proposal, if adopted, would be also unfair on the LIRs who >> *already >> have* taken action to deal with the v4 run-out. That can?t possibly be right. > > Actually no. On the contrary, they may have some fresh air. The only > case where they may be impacted is going to the market and purchasing > a "large enough block" (usually more than a /22). Nope. If I was an LIR who had deployed IPv6 or NAT or bought space because the NCC couldn?t give me more than 1 /22, I?d sue for damages if the policy was later changed to allow multiple /22s. I wouldn?t have had those deployment hassles and costs if the NCC had allocated me a few more /22s. A really angry LIR could go to court for Injunctive Relief and also get their government and regulators to intervene. I hope you agree we don?t want to adopt something which increases the risk of these unpleasantries happening. From jim at rfc1035.com Sat Apr 16 16:51:49 2016 From: jim at rfc1035.com (Jim Reid) Date: Sat, 16 Apr 2016 15:51:49 +0100 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <571234AC.6070108@idsys.ro> References: <570F9005.4090008@ripe.net> <20160414125115.GC25856@gir.theapt.org> <1460799072.3821422.580493209.17E86513@webmail.messagingengine.com> <010AD9D5-E830-4A4B-B979-E0EC38A34B01@rfc1035.com> <571234AC.6070108@idsys.ro> Message-ID: <634EA038-17E7-413D-A70A-0B77CDF42173@rfc1035.com> > On 16 Apr 2016, at 13:48, Adrian Pitulac wrote: > > Will the 185/8 going to being depleted by new LIRs in 10 months? I'm I missing something? Yes. Allocations from 185/8 wouldn?t just go to new LIRs. And besides it?s not just allocations from that /8 that would be affected by this proposal. As Remco has already pointed out, the final /8 policy "was never about what to do with specifically 185/8, but what to do with all future allocations from the moment we needed to start allocating out of it. The policy text itself was never limited to a single /8, nor was that limitation any part of the discussion." > Have you really read the policy change, or are you against any policy change by default? I support policy proposals which are sensible and benefit the community. (Same thing really.) 2015-05 does not do that. I have read the policy change and thought about its implications. I suggest you look at the first two bullet points listed under "Arguments opposing the proposal?. These are two of the main reasons why this proposal has to be rejected. The first one is a show-stopper. It?s more than enough reason to kill this proposal. From jim at rfc1035.com Sat Apr 16 17:10:58 2016 From: jim at rfc1035.com (Jim Reid) Date: Sat, 16 Apr 2016 16:10:58 +0100 Subject: [address-policy-wg] Litigation for fun and profit In-Reply-To: References: <570F9005.4090008@ripe.net> <20160414125115.GC25856@gir.theapt.org> <1460799072.3821422.580493209.17E86513@webmail.messagingengine.com> <010AD9D5-E830-4A4B-B979-E0EC38A34B01@rfc1035.com> Message-ID: <62E118FB-35F9-4028-8415-20DBA7B3CDAB@rfc1035.com> > On 16 Apr 2016, at 14:53, Dominik Nowacki wrote: > > And such LIR would sue who? Himself? RIPE NCC is not a government body, nor a private company. It's an organisation of members, and such a LIR would have to be a member with set voting rights. You can't really sue for policy changes because you don't like how other, equal members voted. They?d start by suing the NCC for implementing a policy which has done harm to the LIR?s business. If they were vindictive, they?d also go after the authors of the policy change, the individuals who supported that policy proposal and those who had a hand in making the consensus judgement. Whether these hypothetical actions might be ultimately successful or not is irrelevant. [FWIW there?s no point debating here how many lawyers can dance on the head of this pin. It?s also a side issue compared to the main problems raised by 2015-05.] However the stink arising from such action(s) would get the attention of governments and regulators. That would be Bad. Defending these lawsuits would not be cheap either. BTW, nobody ?votes? on address policy. That?s decided by the RIPE community. Which is not the same thing as the RIPE NCC membership. RIPE?s decisions are made by consensus. NCC members get to vote for board candidates, the charging scheme and the organisation?s activity plan. Anyone can take part in RIPE policy-making. They don?t have to be a RIPE NCC member. From nick at foobar.org Sat Apr 16 17:32:39 2016 From: nick at foobar.org (Nick Hilliard) Date: Sat, 16 Apr 2016 16:32:39 +0100 Subject: [address-policy-wg] Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <571223E9.90606@wirem.net> References: <570F9005.4090008@ripe.net> <571080B4.70101@wirem.net> <57121BDF.6020706@foobar.org> <571223E9.90606@wirem.net> Message-ID: <57125B17.4090608@foobar.org> Riccardo Gori wrote: > This proposal aims to address the real need [...] Nearly everyone has a need for more IP addresses, not just those with less than /20. The need that organisations have for more IPv4 addresses isn't in dispute. The question is who pays for this need. 2015-05 proposes that we mortgage away the requirements of future market entrants in order to service the community's need right now. There are good reasons why the community should do this and equally - or depending on your point of view, maybe even better - reasons not to do so. My personal opinion is that given the problems this will create for future Internet market entrants, I don't see sufficiently compelling reasons to change the policy. I respect the fact that you see things differently. When you're scraping the bottom of a barrel, disagreements are bound to happen about who gets what dregs and when, and these disagreements will continue as long as there is a single address block remaining in the RIPE NCC IPv4 allocation pool. One of the few disadvantages with the current policy that we can all agree on is that it will prolong these disagreements compared to other policies which favour faster runout. Nick From adrian at idsys.ro Sat Apr 16 17:35:24 2016 From: adrian at idsys.ro (Adrian Pitulac) Date: Sat, 16 Apr 2016 18:35:24 +0300 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <634EA038-17E7-413D-A70A-0B77CDF42173@rfc1035.com> References: <570F9005.4090008@ripe.net> <20160414125115.GC25856@gir.theapt.org> <1460799072.3821422.580493209.17E86513@webmail.messagingengine.com> <010AD9D5-E830-4A4B-B979-E0EC38A34B01@rfc1035.com> <571234AC.6070108@idsys.ro> <634EA038-17E7-413D-A70A-0B77CDF42173@rfc1035.com> Message-ID: <57125BBC.5050806@idsys.ro> >> On 16 Apr 2016, at 13:48, Adrian Pitulac wrote: >> >> Will the 185/8 going to being depleted by new LIRs in 10 months? I'm I missing something? > Yes. Allocations from 185/8 wouldn?t just go to new LIRs. And besides it?s not just allocations from that /8 that would be affected by this proposal. > > As Remco has already pointed out, the final /8 policy "was never about what to do with specifically 185/8, but what to do with all future allocations from the moment we needed to start allocating out of it. The policy text itself was never limited to a single /8, nor was that limitation any part of the discussion." > I thought I've missed something when you wrote that and I've re-read the policy change proposal. To me it "1. The size of the allocation made from 185/8 will be exactly one /22." this sounds like allocations from 185/8 will be as till now. Then " 3.2. There is enough space in the free pool outside the 185/8 block to perform the allocation." CLEARLY STATES 185/8 won't be used for the subsequent allocations. How on earth did you reach the conclusion that 185/8 will be depleted in 10 months? >> Have you really read the policy change, or are you against any policy change by default? > I support policy proposals which are sensible and benefit the community. (Same thing really.) > 2015-05 does not do that. > > I have read the policy change and thought about its implications. I suggest you look at the first two bullet points listed under "Arguments opposing the proposal?. These are two of the main reasons why this proposal has to be rejected. The first one is a show-stopper. It?s more than enough reason to kill this proposal. Yes. I've read it (now twice) and it seems to me you are missing small points in it. "Further allocations will speed up the depletion of the free pool. If every member holding less than a total of /20 addresses would submit a request for a new /22 allocation every 18 months, the recovered pool could be depleted in 2-3 years from now." From what I see they are talking about recovered IANA pool space. So I don't see a problem if that's going to be used in 2-3 years, considering 185/8 will remain for future new LIR's, as intended from the start. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe-wgs at radu-adrian.feurdean.net Sat Apr 16 18:56:17 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Sat, 16 Apr 2016 18:56:17 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <570F9005.4090008@ripe.net> <20160414125115.GC25856@gir.theapt.org> <44515e0cc3a4bab757dbf0bab60999fe@gadago.net> <20160415081645.GE25856@gir.theapt.org> <1460803785.3840375.580539225.0273B0E7@webmail.messagingengine.com> Message-ID: <1460825777.651963.580709793.1316B851@webmail.messagingengine.com> On Sat, Apr 16, 2016, at 13:36, Jim Reid wrote: > > > On 16 Apr 2016, at 11:49, Radu-Adrian FEURDEAN wrote: > > > > ... and there are other markets where "no dedicated IPv4 per customer" > > equals no business. > > And these other markets are either dead or dying because there is no more > IPv4. Some might survive if they can adapt to reality in time. > > Any current business model which depends on issuing a dedicated (public?) > IPv4 addresses to new customers is doomed. That model is simply not > sustainable any more. Either change the model or go bust. Pick one. For the moment it's "change model *AND* go bust". Or "refuse and try to survive" (but ultimately fail 95% of the time, with the current rules). Customers don't care very much about IPv6, CGN doesn't always work, transfer market is at a point difficult ot reach. Or you can just let "incumbets" develop a monopoly. From jim at rfc1035.com Sat Apr 16 19:00:02 2016 From: jim at rfc1035.com (Jim Reid) Date: Sat, 16 Apr 2016 18:00:02 +0100 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <57125BBC.5050806@idsys.ro> References: <570F9005.4090008@ripe.net> <20160414125115.GC25856@gir.theapt.org> <1460799072.3821422.580493209.17E86513@webmail.messagingengine.com> <010AD9D5-E830-4A4B-B979-E0EC38A34B01@rfc1035.com> <571234AC.6070108@idsys.ro> <634EA038-17E7-413D-A70A-0B77CDF42173@rfc1035.com> <57125BBC.5050806@idsys.ro> Message-ID: > On 16 Apr 2016, at 16:35, Adrian Pitulac wrote: > > How on earth did you reach the conclusion that 185/8 will be depleted in 10 months? I didn?t. You?re putting words in my mouth. I actually said "This proposal, if adopted, would pretty much guarantee the free pool would not survive 10 months. That is one of the reasons why I oppose it.? You?re obsessing about the absolute value of a number in an off-the-cuff rhetorical comment. Whether the free pool gets exhausted in 9 months or 11 months or 10.001 months or 10.002 months as a result of this proposal simply does not matter. It?s clearly going to get wiped out sooner than it would under the current policy. Picking nits over guesses/assumptions about when this event happens makes no difference to the outcome. We still run out of IPv4 sooner than we would with the current policy. That?s the inconvenient truth. Supporters of 2015-05 must address this, excuse the pun. 2015-05 clearly states "Further allocations will speed up the depletion of the free pool.?. The object of 2015-05 is to allow further allocations. Therefore it will will speed up the depletion of the free pool. I oppose a policy proposal which has this aim and has no supporting facts to justify taking that course. I?ve listed several reasons for rejecting 2015-05 already and do not need to repeat them. Supporters of this proposal are welcome to present evidence which shows why those reasons are mistaken or wrong. Or why the proposed policy would be better for the RIPE community than the current one. For some definition of better... To date, all that?s been provided is a rag-bag of noise, non-sequiturs and vague references to unsustainable business models. If there?s a sensible or compelling justification to rapidly burn through the last dregs of IPv4, let's hear it. From ripe-wgs at radu-adrian.feurdean.net Sat Apr 16 21:16:34 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Sat, 16 Apr 2016 21:16:34 +0200 Subject: [address-policy-wg] Litigation for fun and profit In-Reply-To: <62E118FB-35F9-4028-8415-20DBA7B3CDAB@rfc1035.com> References: <570F9005.4090008@ripe.net> <20160414125115.GC25856@gir.theapt.org> <1460799072.3821422.580493209.17E86513@webmail.messagingengine.com> <010AD9D5-E830-4A4B-B979-E0EC38A34B01@rfc1035.com> <62E118FB-35F9-4028-8415-20DBA7B3CDAB@rfc1035.com> Message-ID: <1460834194.686759.580712449.619F24BD@webmail.messagingengine.com> On Sat, Apr 16, 2016, at 17:10, Jim Reid wrote: > > > On 16 Apr 2016, at 14:53, Dominik Nowacki wrote: > > > > And such LIR would sue who? Himself? RIPE NCC is not a government body, nor a private company. It's an organisation of members, and such a LIR would have to be a member with set voting rights. You can't really sue for policy changes because you don't like how other, equal members voted. > > They?d start by suing the NCC for implementing a policy which has done > harm to the LIR?s business. If they were vindictive, they?d also go after Here we are in the FUD domain. I think we should not go that way. > the authors of the policy change, the individuals who supported that > policy proposal and those who had a hand in making the consensus > judgement. I, as a proposer would not fear about that. Justice is complex in its own, international justice (neither of the proposers live in UK or NL) is even more complex. > action(s) would get the attention of governments and regulators. That would be Bad. Regulators may end up acting in either direction (for or against). > decisions are made by consensus. NCC members get to vote for board > candidates, the charging scheme and the organisation?s activity plan. And in certain circumstances, on other things.... From ripe-wgs at radu-adrian.feurdean.net Sat Apr 16 21:41:49 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Sat, 16 Apr 2016 21:41:49 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <20160415203327.GB31001@danton.fire-world.de> References: <5710AE13.8060201@idsys.ro> <4DF65647-8E27-4B62-805A-BFBB79C3B895@ecs.soton.ac.uk> <5710EDAD.2000406@idsys.ro> <571117E6.6050907@idsys.ro> <57112464.7020103@i-net.bg> <20160415182359.GA56633@Space.Net> <57113A0D.7020704@idsys.ro> <20160415203327.GB31001@danton.fire-world.de> Message-ID: <1460835709.692516.580789321.7E6252B5@webmail.messagingengine.com> On Fri, Apr 15, 2016, at 22:33, Sebastian Wiesinger wrote: > Most bigger LIRs make money by connecting people to the internet, > believe it or not. The motivation to make money by selling address > blocks only started a while ago and by my observation it's not It's not the "selling addresses" part that gives them unfair advantage. It's "being able to include them in the service" (as per customer's demand) that puts them in an unfairly comfortable position. Basically: there is a race. If you are an old competitor, you can compete as usual. If you are a new one (less that 3 years), you start with 10L of fuel and you get a 30 sec penalty every time you refill. From aled.w.morris at googlemail.com Sat Apr 16 21:58:17 2016 From: aled.w.morris at googlemail.com (Aled Morris) Date: Sat, 16 Apr 2016 20:58:17 +0100 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <1460835709.692516.580789321.7E6252B5@webmail.messagingengine.com> References: <5710AE13.8060201@idsys.ro> <4DF65647-8E27-4B62-805A-BFBB79C3B895@ecs.soton.ac.uk> <5710EDAD.2000406@idsys.ro> <571117E6.6050907@idsys.ro> <57112464.7020103@i-net.bg> <20160415182359.GA56633@Space.Net> <57113A0D.7020704@idsys.ro> <20160415203327.GB31001@danton.fire-world.de> <1460835709.692516.580789321.7E6252B5@webmail.messagingengine.com> Message-ID: On 16 April 2016 at 20:41, Radu-Adrian FEURDEAN < ripe-wgs at radu-adrian.feurdean.net> wrote: > Basically: there is a race. If you are an old competitor, you can > compete as usual. If you are a new one (less that 3 years), you start > with 10L of fuel and you get a 30 sec penalty every time you refill. > The question is, should RIPE be trying to "level the playing field" i.e. interfering in the market? Would it even work if they tried? The argument has been well made that RIPE's role in dishing out IP addresses should be just that - making sure that there will be addresses to give when new members need them, not playing politics, re-jigging the pool of free addresses to "fix" a business problem that a subset of the members believe they are suffering. I'm reminded of government intervention to "fix" the problems of broadband availability where rural areas feel they are disadvantaged. The result? hundreds of thousands of pounds of taxpayers money wasted on crap satellite internet connections. Nobody wins. Aled -------------- next part -------------- An HTML attachment was scrubbed... URL: From h.lu at anytimechinese.com Sun Apr 17 01:46:12 2016 From: h.lu at anytimechinese.com (h.lu at anytimechinese.com) Date: Sun, 17 Apr 2016 07:46:12 +0800 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <5710AE13.8060201@idsys.ro> <4DF65647-8E27-4B62-805A-BFBB79C3B895@ecs.soton.ac.uk> <5710EDAD.2000406@idsys.ro> <571117E6.6050907@idsys.ro> <57112464.7020103@i-net.bg> <20160415182359.GA56633@Space.Net> <57113A0D.7020704@idsys.ro> <20160415203327.GB31001@danton.fire-world.de> <1460835709.692516.580789321.7E6252B5@webmail.messagingengine.com> Message-ID: Hey I seriously liking the idea of some APNIC colleagues "no more v4 policy from today on". All those growth thing, when was last time you saw a property developer complaint to Gov that he can not grow his business because he can not get free land? No one would be stopped doing business because of 10% more expenditure(in which at today's v4 price, not even 10%). Naming any possible business form needing IP address, I fairly confident all of them, IP won't count even 5% of their total expenditure. (You pay 1000USD to get your user connected, really 10 more USD will bankrupt you?) So the guys are doing the right business, will grow regardless. The guy aren't even survive IP price, will likely not survive many other things--so why we cares. My suggestions are get over it, leave the v4 alone. > On 17 Apr 2016, at 03:58, Aled Morris wrote: > >> On 16 April 2016 at 20:41, Radu-Adrian FEURDEAN wrote: >> Basically: there is a race. If you are an old competitor, you can >> compete as usual. If you are a new one (less that 3 years), you start >> with 10L of fuel and you get a 30 sec penalty every time you refill. > > The question is, should RIPE be trying to "level the playing field" i.e. interfering in the market? Would it even work if they tried? > > The argument has been well made that RIPE's role in dishing out IP addresses should be just that - making sure that there will be addresses to give when new members need them, not playing politics, re-jigging the pool of free addresses to "fix" a business problem that a subset of the members believe they are suffering. > > I'm reminded of government intervention to "fix" the problems of broadband availability where rural areas feel they are disadvantaged. The result? hundreds of thousands of pounds of taxpayers money wasted on crap satellite internet connections. Nobody wins. > > Aled -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Sun Apr 17 03:58:53 2016 From: randy at psg.com (Randy Bush) Date: Sun, 17 Apr 2016 10:58:53 +0900 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <5710AE13.8060201@idsys.ro> <4DF65647-8E27-4B62-805A-BFBB79C3B895@ecs.soton.ac.uk> <5710EDAD.2000406@idsys.ro> <571117E6.6050907@idsys.ro> <57112464.7020103@i-net.bg> <20160415182359.GA56633@Space.Net> <57113A0D.7020704@idsys.ro> <20160415203327.GB31001@danton.fire-world.de> <1460835709.692516.580789321.7E6252B5@webmail.messagingengine.com> Message-ID: > I seriously liking the idea of some APNIC colleagues "no more v4 > policy from today on". that was my proposal. the sitting apnic address policy chair went into bureaucratic insanity and drowned it. we could try it here. randy From h.lu at anytimechinese.com Sun Apr 17 04:16:09 2016 From: h.lu at anytimechinese.com (Lu Heng) Date: Sun, 17 Apr 2016 10:16:09 +0800 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <5710AE13.8060201@idsys.ro> <4DF65647-8E27-4B62-805A-BFBB79C3B895@ecs.soton.ac.uk> <5710EDAD.2000406@idsys.ro> <571117E6.6050907@idsys.ro> <57112464.7020103@i-net.bg> <20160415182359.GA56633@Space.Net> <57113A0D.7020704@idsys.ro> <20160415203327.GB31001@danton.fire-world.de> <1460835709.692516.580789321.7E6252B5@webmail.messagingengine.com> Message-ID: On Sunday 17 April 2016, Randy Bush wrote: > > I seriously liking the idea of some APNIC colleagues "no more v4 > > policy from today on". > > that was my proposal. the sitting apnic address policy chair went into > bureaucratic insanity and drowned it. Hoesntly, I think it is best companion policy goes alone with the last /8 policy, as we all know and expected people would love to come back propose to get the last piece of free pile eatted now instead of in few years. V4 are not like guns, someone holding it won't cause danger to anyone. And we don't really dealing with abuse in the policy, and we don't have any v4 left to distribute. So why we need further policy proposal regarding something that policy can not manage, control, distribute, so what for? The policy exists at start mostly for fair distribution, book keeper job so internet can function, now distribution job is done, book keep only requires transparency and easy for anyone update their record honestly without worrying anything, that's how we get best registry job done. > we could try it here. > > randy > -- -- Kind regards. Lu -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Sun Apr 17 04:22:29 2016 From: randy at psg.com (Randy Bush) Date: Sun, 17 Apr 2016 11:22:29 +0900 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <5710AE13.8060201@idsys.ro> <4DF65647-8E27-4B62-805A-BFBB79C3B895@ecs.soton.ac.uk> <5710EDAD.2000406@idsys.ro> <571117E6.6050907@idsys.ro> <57112464.7020103@i-net.bg> <20160415182359.GA56633@Space.Net> <57113A0D.7020704@idsys.ro> <20160415203327.GB31001@danton.fire-world.de> <1460835709.692516.580789321.7E6252B5@webmail.messagingengine.com> Message-ID: >>> I seriously liking the idea of some APNIC colleagues "no more v4 >>> policy from today on". >> that was my proposal. the sitting apnic address policy chair went into >> bureaucratic insanity and drowned it. > Hoesntly, I think it is best companion policy goes alone with the last > /8 policy, as we all know and expected people would love to come back > propose to get the last piece of free pile eatted now instead of in > few years. well, it is some years too late for it to go along with the last /8, policy unless you have a time machine. but it might mean we won't have to deal with the endless proposals to modify the last /8 policy which seem to come up every year, flood the mailing list, and eventually fail. randy From h.lu at anytimechinese.com Sun Apr 17 04:30:57 2016 From: h.lu at anytimechinese.com (Lu Heng) Date: Sun, 17 Apr 2016 10:30:57 +0800 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <5710AE13.8060201@idsys.ro> <4DF65647-8E27-4B62-805A-BFBB79C3B895@ecs.soton.ac.uk> <5710EDAD.2000406@idsys.ro> <571117E6.6050907@idsys.ro> <57112464.7020103@i-net.bg> <20160415182359.GA56633@Space.Net> <57113A0D.7020704@idsys.ro> <20160415203327.GB31001@danton.fire-world.de> <1460835709.692516.580789321.7E6252B5@webmail.messagingengine.com> Message-ID: On Sunday 17 April 2016, Randy Bush wrote: > >>> I seriously liking the idea of some APNIC colleagues "no more v4 > >>> policy from today on". > >> that was my proposal. the sitting apnic address policy chair went into > >> bureaucratic insanity and drowned it. > > Hoesntly, I think it is best companion policy goes alone with the last > > /8 policy, as we all know and expected people would love to come back > > propose to get the last piece of free pile eatted now instead of in > > few years. > > well, it is some years too late for it to go along with the last /8, > policy unless you have a time machine. but it might mean we won't have > to deal with the endless proposals to modify the last /8 policy which > seem to come up every year, flood the mailing list, and eventually fail. > > Exactly, the sad part is, this is essentially the last and only thing you can propose a policy regarding v4. But if it is indeed the only thing you can propose about v4(to distribute last /8 faster than now), and most folks here agree that we shouldn't do that, then it is a simple logic, the only policy you can propose regarding v4 will be something people surely disagree, why would we need future proposal regarding v4. randy > -- -- Kind regards. Lu -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Sun Apr 17 04:50:11 2016 From: randy at psg.com (Randy Bush) Date: Sun, 17 Apr 2016 11:50:11 +0900 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <5710AE13.8060201@idsys.ro> <4DF65647-8E27-4B62-805A-BFBB79C3B895@ecs.soton.ac.uk> <5710EDAD.2000406@idsys.ro> <571117E6.6050907@idsys.ro> <57112464.7020103@i-net.bg> <20160415182359.GA56633@Space.Net> <57113A0D.7020704@idsys.ro> <20160415203327.GB31001@danton.fire-world.de> <1460835709.692516.580789321.7E6252B5@webmail.messagingengine.com> Message-ID: >> well, it is some years too late for it to go along with the last /8, >> policy unless you have a time machine. but it might mean we won't have >> to deal with the endless proposals to modify the last /8 policy which >> seem to come up every year, flood the mailing list, and eventually fail. > Exactly, the sad part is, this is essentially the last and only thing you > can propose a policy regarding v4. not exactly. one can propose something in the opposite direction; allocations from the last /8 be reduced to /24. it may make ipv4 last longer for the new entrants. and a /24 should be sufficient for a large nat. i.e. i was serious the other day. randy From h.lu at anytimechinese.com Sun Apr 17 04:59:56 2016 From: h.lu at anytimechinese.com (Lu Heng) Date: Sun, 17 Apr 2016 10:59:56 +0800 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <5710AE13.8060201@idsys.ro> <4DF65647-8E27-4B62-805A-BFBB79C3B895@ecs.soton.ac.uk> <5710EDAD.2000406@idsys.ro> <571117E6.6050907@idsys.ro> <57112464.7020103@i-net.bg> <20160415182359.GA56633@Space.Net> <57113A0D.7020704@idsys.ro> <20160415203327.GB31001@danton.fire-world.de> <1460835709.692516.580789321.7E6252B5@webmail.messagingengine.com> Message-ID: On Sunday 17 April 2016, Randy Bush wrote: > >> well, it is some years too late for it to go along with the last /8, > >> policy unless you have a time machine. but it might mean we won't have > >> to deal with the endless proposals to modify the last /8 policy which > >> seem to come up every year, flood the mailing list, and eventually fail. > > Exactly, the sad part is, this is essentially the last and only thing you > > can propose a policy regarding v4. > > not exactly. one can propose something in the opposite direction; > allocations from the last /8 be reduced to /24. it may make ipv4 > last longer for the new entrants. and a /24 should be sufficient > for a large nat. > > i.e. i was serious the other day. Well, if you do, make sure take the companion policy with you this time:) otherwise we might go though the discussion we had this time(distribute it faster) every year for a very long time:) P.s.i have no objection to future extend the last /8, but simple economics suggest it might not work as new member would be effectively be charged at 5 euro/IP/year if they only get /24, and changing member charging scheme are very difficult and unlikely to happen. But, it does provide an hassal free way for small companies get their own IP address for a long time to come as transfer market are still not that transparent and easy to deal with. > > randy > -- -- Kind regards. Lu -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian at idsys.ro Sun Apr 17 08:52:15 2016 From: adrian at idsys.ro (Adrian Pitulac) Date: Sun, 17 Apr 2016 09:52:15 +0300 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <5710AE13.8060201@idsys.ro> <5710EDAD.2000406@idsys.ro> <571117E6.6050907@idsys.ro> <57112464.7020103@i-net.bg> <20160415182359.GA56633@Space.Net> <57113A0D.7020704@idsys.ro> <20160415203327.GB31001@danton.fire-world.de> <1460835709.692516.580789321.7E6252B5@webmail.messagingengine.com> Message-ID: <5713329F.9000900@idsys.ro> On 17/04/16 05:50, Randy Bush wrote: >>> well, it is some years too late for it to go along with the last /8, >>> policy unless you have a time machine. but it might mean we won't have >>> to deal with the endless proposals to modify the last /8 policy which >>> seem to come up every year, flood the mailing list, and eventually fail. >> Exactly, the sad part is, this is essentially the last and only thing you >> can propose a policy regarding v4. > not exactly. one can propose something in the opposite direction; > allocations from the last /8 be reduced to /24. it may make ipv4 > last longer for the new entrants. and a /24 should be sufficient > for a large nat. > > i.e. i was serious the other day. > > randy > I see the same explanation again and again and again. But I see no real argument from you guys. No statistics, no trending, no prediction, just "keep the ipv4 last longer". Can you do better than that? From frettled at gmail.com Sun Apr 17 09:01:18 2016 From: frettled at gmail.com (Jan Ingvoldstad) Date: Sun, 17 Apr 2016 09:01:18 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <5713329F.9000900@idsys.ro> References: <5710AE13.8060201@idsys.ro> <5710EDAD.2000406@idsys.ro> <571117E6.6050907@idsys.ro> <57112464.7020103@i-net.bg> <20160415182359.GA56633@Space.Net> <57113A0D.7020704@idsys.ro> <20160415203327.GB31001@danton.fire-world.de> <1460835709.692516.580789321.7E6252B5@webmail.messagingengine.com> <5713329F.9000900@idsys.ro> Message-ID: On Sun, Apr 17, 2016 at 8:52 AM, Adrian Pitulac wrote: > > I see the same explanation again and again and again. But I see no real > argument from you guys. No statistics, no trending, no prediction, just > "keep the ipv4 last longer". Can you do better than that? > > Is this your best argument *for* the policy? That you haven't read enough posts well enough to find the arguments against, nor to find the statistics, the trends, the predictions? Seriously? -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian at idsys.ro Sun Apr 17 09:31:04 2016 From: adrian at idsys.ro (Adrian Pitulac) Date: Sun, 17 Apr 2016 10:31:04 +0300 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <5710AE13.8060201@idsys.ro> <5710EDAD.2000406@idsys.ro> <571117E6.6050907@idsys.ro> <57112464.7020103@i-net.bg> <20160415182359.GA56633@Space.Net> <57113A0D.7020704@idsys.ro> <20160415203327.GB31001@danton.fire-world.de> <1460835709.692516.580789321.7E6252B5@webmail.messagingengine.com> <5713329F.9000900@idsys.ro> Message-ID: <57133BB8.4030201@idsys.ro> On 17/04/16 10:01, Jan Ingvoldstad wrote: > On Sun, Apr 17, 2016 at 8:52 AM, Adrian Pitulac > wrote: > > > I see the same explanation again and again and again. But I see no > real argument from you guys. No statistics, no trending, no > prediction, just "keep the ipv4 last longer". Can you do better > than that? > > > Is this your best argument *for* the policy? That you haven't read > enough posts well enough to find the arguments against, nor to find > the statistics, the trends, the predictions? Seriously? > -- > Jan Jan, I think you should read my previous posts, I've come up with several arguments, none of which have been seriously discussed and analyzed. Also FYI I've been reading the discussions here for a long time, and this intervention is my first because I see the same explanation again and again without no base. This should be a discussion on arguments not just a presentation of personal "default" denial of any change to policy. This is what I saw until now. I was under the impression that people here can start a discussion and analyze the *for* and *against* arguments until we reach a conclusion. Am I wrong? -------------- next part -------------- An HTML attachment was scrubbed... URL: From frettled at gmail.com Sun Apr 17 09:42:39 2016 From: frettled at gmail.com (Jan Ingvoldstad) Date: Sun, 17 Apr 2016 09:42:39 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <57133BB8.4030201@idsys.ro> References: <5710AE13.8060201@idsys.ro> <5710EDAD.2000406@idsys.ro> <571117E6.6050907@idsys.ro> <57112464.7020103@i-net.bg> <20160415182359.GA56633@Space.Net> <57113A0D.7020704@idsys.ro> <20160415203327.GB31001@danton.fire-world.de> <1460835709.692516.580789321.7E6252B5@webmail.messagingengine.com> <5713329F.9000900@idsys.ro> <57133BB8.4030201@idsys.ro> Message-ID: On Sun, Apr 17, 2016 at 9:31 AM, Adrian Pitulac wrote: > > > Jan, I think you should read my previous posts, I've come up with several > arguments, none of which have been seriously discussed and analyzed. > I have read your arguments, and they have been previously discussed and analyzed. > > Also FYI I've been reading the discussions here for a long time, and this > intervention is my first because I see the same explanation again and again > without no base. > > This should be a discussion on arguments not just a presentation of > personal "default" denial of any change to policy. This is what I saw until > now. I was under the impression that people here can start a discussion and > analyze the *for* and *against* arguments until we reach a conclusion. Am I > wrong? > > Well, insofar that you yourself have not presented any thorough arguments or analysis yourself, you are right. But others have. That you choose to disregard these arguments and analysis, is really your problem, and your problem alone. Repeating your talking point does not help, and it only makes your arguments look weaker. Frankly, your arguments have made me even more certain that this policy needs to be stopped, and the current policy has to stay in place to ensure some opportunity for future entrants. PS: My point of view directly disadvantages my employer, who could stand to gain financially from the proposal, which allows for more stockpiling of IPv4 resources for future scarcity. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Sun Apr 17 10:35:43 2016 From: gert at space.net (Gert Doering) Date: Sun, 17 Apr 2016 10:35:43 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <5713329F.9000900@idsys.ro> References: <20160415203327.GB31001@danton.fire-world.de> <1460835709.692516.580789321.7E6252B5@webmail.messagingengine.com> <5713329F.9000900@idsys.ro> Message-ID: <20160417083543.GI56633@Space.Net> Hi, On Sun, Apr 17, 2016 at 09:52:15AM +0300, Adrian Pitulac wrote: > I see the same explanation again and again and again. But I see no real > argument from you guys. No statistics, no trending, no prediction, just > "keep the ipv4 last longer". Can you do better than that? Marco has provided statistics about the IPv4 pool runout, broken down by "185" and "other addresses returned". These show that while the total number of addresses in the NCC stock is sort of "keeping up", about half of 185 is used up - so with the current trend going on, 185 will be used up in 2018-2019 or so https://labs.ripe.net/Members/marco_schmidt/taking-a-closer-look-at-the-last-slash-8 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: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From h.lu at anytimechinese.com Sun Apr 17 10:42:25 2016 From: h.lu at anytimechinese.com (Lu Heng) Date: Sun, 17 Apr 2016 16:42:25 +0800 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <20160417083543.GI56633@Space.Net> References: <20160415203327.GB31001@danton.fire-world.de> <1460835709.692516.580789321.7E6252B5@webmail.messagingengine.com> <5713329F.9000900@idsys.ro> <20160417083543.GI56633@Space.Net> Message-ID: Hi I think an more interesting break down would be the companies' business(e.g the industry they are in) As I understand, more and more end user are becoming LIR as their ISP refuse to give them IP, therefore it fundamentally changed the very definition of LIR. The outbreak in the member mailing list last time reminds us how big that group could be. What current ISP doing nowadays, instead of charging customer and apply to RIPE for their customer's IP, they ask their customer come to RIPE to become their own LIR and get their own IP then manage it for the customer. In which, results what we see today, shipping companies, banks, even airlines become LIR. On Sunday 17 April 2016, Gert Doering wrote: > Hi, > > On Sun, Apr 17, 2016 at 09:52:15AM +0300, Adrian Pitulac wrote: > > I see the same explanation again and again and again. But I see no real > > argument from you guys. No statistics, no trending, no prediction, just > > "keep the ipv4 last longer". Can you do better than that? > > Marco has provided statistics about the IPv4 pool runout, broken down by > "185" and "other addresses returned". These show that while the total > number of addresses in the NCC stock is sort of "keeping up", about half > of 185 is used up - so with the current trend going on, 185 will be > used up in 2018-2019 or so > > > https://labs.ripe.net/Members/marco_schmidt/taking-a-closer-look-at-the-last-slash-8 > > 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 > -- -- Kind regards. Lu -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.petrov at i-net.bg Sun Apr 17 11:06:34 2016 From: m.petrov at i-net.bg (Momchil Petrov) Date: Sun, 17 Apr 2016 12:06:34 +0300 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <20160415203327.GB31001@danton.fire-world.de> <1460835709.692516.580789321.7E6252B5@webmail.messagingengine.com> <5713329F.9000900@idsys.ro> <20160417083543.GI56633@Space.Net> Message-ID: <5713521A.4010803@i-net.bg> i'll try to see in the future... Small LIR will register on different company (or daughter) LIR just to take a "only one /22" many other companies will becoma a LIR just to take v4 IPs. It's cheaper than >10 EUR/ip, right (this is already happening). Imagine after some period of time how much voting power they will have ! Well, this proposal may be accepted or may not, but in several years... think about it, will there be a v4 space for a new entrance hmmm Following is to those who will vote "against" Don't think only for the upcoming LIRs, try to understand current ones with "only one /22" ...and don't run away with "membership is for voting, not for space allocation" because with your vote you'll decide allocation p.s. why unused space can be owned by non-working companies? and this space comes on market like "never announced space" - who need of such space Cheers, Momchil On 17.4.2016 ?. 11:42 ?., Lu Heng wrote: > Hi > > I think an more interesting break down would be the companies' > business(e.g the industry they are in) > > As I understand, more and more end user are becoming LIR as their ISP > refuse to give them IP, therefore it fundamentally changed the > very definition of LIR. > > The outbreak in the member mailing list last time reminds us how big > that group could be. > > What current ISP doing nowadays, instead of charging customer and > apply to RIPE for their customer's IP, they ask their customer come to > RIPE to become their own LIR and get their own IP then manage it for > the customer. In which, results what we see today, shipping companies, > banks, even airlines become LIR. > > > On Sunday 17 April 2016, Gert Doering > wrote: > > Hi, > > On Sun, Apr 17, 2016 at 09:52:15AM +0300, Adrian Pitulac wrote: > > I see the same explanation again and again and again. But I see > no real > > argument from you guys. No statistics, no trending, no > prediction, just > > "keep the ipv4 last longer". Can you do better than that? > > Marco has provided statistics about the IPv4 pool runout, broken > down by > "185" and "other addresses returned". These show that while the total > number of addresses in the NCC stock is sort of "keeping up", > about half > of 185 is used up - so with the current trend going on, 185 will be > used up in 2018-2019 or so > > https://labs.ripe.net/Members/marco_schmidt/taking-a-closer-look-at-the-last-slash-8 > > 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 > > > > -- > -- > Kind regards. > Lu > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjc at ecs.soton.ac.uk Sun Apr 17 12:08:06 2016 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Sun, 17 Apr 2016 11:08:06 +0100 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <1460806599.3851826.580556689.6B4BC0D8@webmail.messagingengine.com> References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <4DF65647-8E27-4B62-805A-BFBB79C3B895@ecs.soton.ac.uk> <5710EDAD.2000406@idsys.ro> <1460806599.3851826.580556689.6B4BC0D8@webmail.messagingengine.com> <0D3ACE20-071A-43EA-A05E-4946D8A1F157@ecs.soton.ac.uk> Message-ID: > On 16 Apr 2016, at 12:36, Radu-Adrian FEURDEAN wrote: > > On Fri, Apr 15, 2016, at 16:09, Tim Chown wrote: > >> As others have said, everyone wants to grow. If you?re starting a new >> venture v6 should be at the heart of what you?re doing. > > This is a good way not to start a business, and if you still do it, not > to have many customers. > No matter how much you have IPv6 at heart, as of 16/04/2016 on most > markets "no IPv4" = "no business". For some customers, they won't use > IPv6 even if you bring it at their doorstep. Been there, done that, > still doing that. I mean design in IPv6 from the outset, not necessarily to try to run IPv6-only. But there are examples of IPv6-only deployments, and in the UK there is now at least one provider selling VPS services as IPv6 by default, charging extra for IPv4, and finding many customers just take the IPv6-only service. Rare, yes, but it?s happening. The point is, as the RIPE NCC have been saying for 5 years now, that we *are* out of IPv4, except for /22?s which are intended give a new LIR enough address space to host public facing services along with a certain level of customer-base with NAT/CGN. The existing policy gives some level of guarantee of /22?s being available for a certain period of time. As for how much time that is, Geoff Huston?s projection at http://www.potaroo.net/tools/ipv4/plotend.png is quite widely cited, and indicates 6 more years at current burn rate (i.e. complete run-out around 2022). I would probably support Randy?s /24 proposal, if it were framed around a certain trigger point, i.e. the remaining pool hitting a certain level, maybe a /10?s worth left, such that /24?s were available further out. It will be interest though to see where the market rate for v4 addresses is by then, especially if IPv6 has a much more significant share of the overall traffic. Tim From jordi.palet at consulintel.es Sun Apr 17 12:31:04 2016 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sun, 17 Apr 2016 12:31:04 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <5710AE13.8060201@idsys.ro> <4DF65647-8E27-4B62-805A-BFBB79C3B895@ecs.soton.ac.uk> <5710EDAD.2000406@idsys.ro> <571117E6.6050907@idsys.ro> <57112464.7020103@i-net.bg> <20160415182359.GA56633@Space.Net> <57113A0D.7020704@idsys.ro> <20160415203327.GB31001@danton.fire-world.de> <1460835709.692516.580789321.7E6252B5@webmail.messagingengine.com> Message-ID: <79E87D21-FECD-4C1E-B11F-F193719E5B25@consulintel.es> I think we need something comprehensive such: 1) Allocations of the last /8 reduced to /24, maybe after a trigger point, such as /10 as Tim mention. 2) We want this for only new entrants ? 3) Mandate to have a credible IPv6 deployment plan for those getting 1) simultaneous to the use of the allocated IPv4 resources, which means getting IPv6 allocation at the same time. 4) May be, no new allocations from recovered resources, which may be kept for emergency situations, experiments, or whatever. 5) No new IPv4 policies. We may debate each point as part of a single policy proposal, or split in several in case is difficult to reach consensus. Randy, I will be happy to work on that if you like a co-author. Regards, Jordi -----Mensaje original----- De: address-policy-wg en nombre de Randy Bush Responder a: Fecha: domingo, 17 de abril de 2016, 4:50 Para: Lu Heng CC: RIPE Address Policy WG Asunto: Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) >>> well, it is some years too late for it to go along with the last /8, >>> policy unless you have a time machine. but it might mean we won't have >>> to deal with the endless proposals to modify the last /8 policy which >>> seem to come up every year, flood the mailing list, and eventually fail. >> Exactly, the sad part is, this is essentially the last and only thing you >> can propose a policy regarding v4. > >not exactly. one can propose something in the opposite direction; >allocations from the last /8 be reduced to /24. it may make ipv4 >last longer for the new entrants. and a /24 should be sufficient >for a large nat. > >i.e. i was serious the other day. > >randy > > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From nick at foobar.org Sun Apr 17 12:43:26 2016 From: nick at foobar.org (Nick Hilliard) Date: Sun, 17 Apr 2016 11:43:26 +0100 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <79E87D21-FECD-4C1E-B11F-F193719E5B25@consulintel.es> References: <5710AE13.8060201@idsys.ro> <5710EDAD.2000406@idsys.ro> <571117E6.6050907@idsys.ro> <57112464.7020103@i-net.bg> <20160415182359.GA56633@Space.Net> <57113A0D.7020704@idsys.ro> <20160415203327.GB31001@danton.fire-world.de> <1460835709.692516.580789321.7E6252B5@webmail.messagingengine.com> <79E87D21-FECD-4C1E-B11F-F193719E5B25@consulintel.es> Message-ID: <571368CE.3030906@foobar.org> JORDI PALET MARTINEZ wrote: > 5) No new IPv4 policies. As much as this might seem like a good idea for stopping the endless arguments about changing the last /8 allocation policy, the only thing which will actually put and end to these arguments is final depletion. Everything else is deck-chair rearrangement. Nick From rogerj at gmail.com Sun Apr 17 19:13:09 2016 From: rogerj at gmail.com (=?UTF-8?Q?Roger_J=C3=B8rgensen?=) Date: Sun, 17 Apr 2016 19:13:09 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <570F9005.4090008@ripe.net> <20160414125115.GC25856@gir.theapt.org> Message-ID: On Fri, Apr 15, 2016 at 12:33 AM, Niall O'Reilly wrote: > On 14 Apr 2016, at 17:01, Jim Reid wrote: > >> I strongly disagree with the proposal > > what Jim said, which you don't need to see again. > Well said, Jim. as Jim said.. I'm also against this policy. -- Roger Jorgensen | ROJO9-RIPE rogerj at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From marty at akamai.com Sun Apr 17 19:42:53 2016 From: marty at akamai.com (Hannigan, Martin) Date: Sun, 17 Apr 2016 17:42:53 +0000 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <79E87D21-FECD-4C1E-B11F-F193719E5B25@consulintel.es> References: <5710AE13.8060201@idsys.ro> <4DF65647-8E27-4B62-805A-BFBB79C3B895@ecs.soton.ac.uk> <5710EDAD.2000406@idsys.ro> <571117E6.6050907@idsys.ro> <57112464.7020103@i-net.bg> <20160415182359.GA56633@Space.Net> <57113A0D.7020704@idsys.ro> <20160415203327.GB31001@danton.fire-world.de> <1460835709.692516.580789321.7E6252B5@webmail.messagingengine.com> , <79E87D21-FECD-4C1E-B11F-F193719E5B25@consulintel.es> Message-ID: <66322279-B5C6-4675-8530-CE33082AB59F@akamai.com> > On Apr 17, 2016, at 03:31, JORDI PALET MARTINEZ wrote: > > I think we need something comprehensive such: > > 1) Allocations of the last /8 reduced to /24, maybe after a trigger point, such as /10 as Tim mention. > 2) We want this for only new entrants ? > 3) Mandate to have a credible IPv6 deployment plan for those getting 1) simultaneous to the use of the allocated IPv4 resources, which means getting IPv6 allocation at the same time. > 4) May be, no new allocations from recovered resources, which may be kept for emergency situations, experiments, or whatever. > 5) No new IPv4 policies. > > We may debate each point as part of a single policy proposal, or split in several in case is difficult to reach consensus. > > Randy, I will be happy to work on that if you like a co-author. > > Regards, > Jordi > > > I like it. I'm in if more are needed Best, Marty > > > > > > > -----Mensaje original----- > De: address-policy-wg en nombre de Randy Bush > Responder a: > Fecha: domingo, 17 de abril de 2016, 4:50 > Para: Lu Heng > CC: RIPE Address Policy WG > Asunto: Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) > >>>> well, it is some years too late for it to go along with the last /8, >>>> policy unless you have a time machine. but it might mean we won't have >>>> to deal with the endless proposals to modify the last /8 policy which >>>> seem to come up every year, flood the mailing list, and eventually fail. >>> Exactly, the sad part is, this is essentially the last and only thing you >>> can propose a policy regarding v4. >> >> not exactly. one can propose something in the opposite direction; >> allocations from the last /8 be reduced to /24. it may make ipv4 >> last longer for the new entrants. and a /24 should be sufficient >> for a large nat. >> >> i.e. i was serious the other day. >> >> randy > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > > > > From daniela at viaturchetta.it Sun Apr 17 20:06:52 2016 From: daniela at viaturchetta.it (daniela at viaturchetta.it) Date: Sun, 17 Apr 2016 20:06:52 +0200 Subject: [address-policy-wg] =?utf-8?q?2015-05_Discussion_Period_extended_?= =?utf-8?q?until_13_May_2016_=28Last_/8_Allocation_Criteria_Revisio?= =?utf-8?q?n=29?= In-Reply-To: <20160417083543.GI56633@Space.Net> References: =?iso-8859-1?q?=3C20160415203327=2EGB31001=40danton=2Efire=2Dworld=2E?= =?iso-8859-1?q?de=3E_=3C1460835709=2E692516=2E580789321=2E7E6252B5=40?= =?iso-8859-1?q?webmail=2Emessagingengine=2Ecom=3E_=3CCAO1bj=3DYjL6cp?= =?iso-8859-1?q?=5FDukF7Y=3Dq9HNBVy2=3DxgcjnxpL3JmojYe=2Dcbt4A=40mail?= =?iso-8859-1?q?=2Egmail=2Ecom=3E_=3CC6717F9F=2D3C9B=2D43C7=2D9341=2D4?= =?iso-8859-1?q?C80CF442085=40anytimechinese=2Ecom=3E_=3Cm2wpnx9esi=2E?= =?iso-8859-1?q?wl=25randy=40psg=2Ecom=3E_=3CCAAvCx3jQd7m9snH4OSUe5srU?= =?iso-8859-1?q?osKfVgYJB5YHx7MsASj6XS=3DMMw=40mail=2Egmail=2Ecom=3E_?= =?iso-8859-1?q?=3Cm2r3e59dp6=2Ewl=25randy=40psg=2Ecom=3E_=3CCAAvCx3i0?= =?iso-8859-1?q?ifB=3DHfjNge1JewK0LoVJ=3DmTQJYQk6MBY=2BG6h8=2D2sjw=40m?= =?iso-8859-1?q?ail=2Egmail=2Ecom=3E_=3Cm2oa999cf0=2Ewl=25randy=40psg?= =?iso-8859-1?q?=2Ecom=3E_=3C5713329F=2E9000900=40idsys=2Ero=3E_=3C201?= =?iso-8859-1?q?60417083543=2EGI56633=40Space=2ENet=3E?= Message-ID: I am in favor this policy Daniela = Daniela Catellani +39 338 8986361 daniela at viaturchetta.it -------------- next part -------------- An HTML attachment was scrubbed... URL: From max at rfc2324.org Sun Apr 17 20:19:37 2016 From: max at rfc2324.org (Maximilian Wilhelm) Date: Sun, 17 Apr 2016 20:19:37 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <20160415201231.GA31001@danton.fire-world.de> References: <570F9005.4090008@ripe.net> <20160415201231.GA31001@danton.fire-world.de> Message-ID: <20160417181937.GB4193@principal.rfc2324.org> Anno domini 2016 Sebastian Wiesinger scripsit: > * Marco Schmidt [2016-04-14 14:45]: > > Dear colleagues, > > > > The Discussion Period for the policy proposal 2015-05, "Last /8 Allocation > > Criteria Revision" has been extended until 13 May 2016. > > > > The goal of this proposal is to allow LIRs to request an additional /22 IPv4 > > allocation from the RIPE NCC every 18 months. > oppose this proposal. As others have already stated, the goal of the > reserved pool is to enable new entrants into the IPv4 market while > we're cleaning up the mess we made by not migrating to IPv6 sooner. > Giving additional allocations to members will not further that goal. +1 Best Max -- Alles sollte so einfach wie m?glich gemacht sein. Aber nicht einfacher. (Einstein) From ripe-wgs at radu-adrian.feurdean.net Sun Apr 17 22:19:04 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Sun, 17 Apr 2016 22:19:04 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <20160415203327.GB31001@danton.fire-world.de> <1460835709.692516.580789321.7E6252B5@webmail.messagingengine.com> <5713329F.9000900@idsys.ro> <20160417083543.GI56633@Space.Net> Message-ID: <1460924344.2551496.581389841.14FDECE9@webmail.messagingengine.com> On Sun, Apr 17, 2016, at 10:42, Lu Heng wrote: > As I understand, more and more end user are becoming LIR as their ISP > refuse to give them IP, therefore it fundamentally changed the > very definition of LIR. > > The outbreak in the member mailing list last time reminds us how big that > group could be. > > What current ISP doing nowadays, instead of charging customer and apply to > RIPE for their customer's IP, they ask their customer come to RIPE to > become their own LIR and get their own IP then manage it for the customer. > In which, results what we see today, shipping companies, banks, even > airlines become LIR. Hi, This is exactly the point where the community failed. We keep saying that there is no more IPv4, and in the meanwhile more and more companies (non-ISP) discover that they can still get their needed IPv4 space, with the bonus of becoming provider independent. In the process of doing this, they "eat up" a /22 even if they only need a /23 or a /24 (or less, but that can't be routed). At the same time they still hear (for more than 10 years already) that IPv6 is coming, but still don't see it "coming close enough" (no, they don't really care about Google, FB, and Netflix - and if they do, it's more about how to block them). From m.petrov at i-net.bg Sun Apr 17 23:00:04 2016 From: m.petrov at i-net.bg (Momchil Petrov) Date: Mon, 18 Apr 2016 00:00:04 +0300 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <1460924344.2551496.581389841.14FDECE9@webmail.messagingengine.com> References: <20160415203327.GB31001@danton.fire-world.de> <1460835709.692516.580789321.7E6252B5@webmail.messagingengine.com> <5713329F.9000900@idsys.ro> <20160417083543.GI56633@Space.Net> <1460924344.2551496.581389841.14FDECE9@webmail.messagingengine.com> Message-ID: <5713F954.2000609@i-net.bg> +100 the statistic saying the same, more and more will be Momchil On 17.4.2016 ?. 23:19 ?., Radu-Adrian FEURDEAN wrote: > On Sun, Apr 17, 2016, at 10:42, Lu Heng wrote: >> As I understand, more and more end user are becoming LIR as their ISP >> refuse to give them IP, therefore it fundamentally changed the >> very definition of LIR. >> >> The outbreak in the member mailing list last time reminds us how big that >> group could be. >> >> What current ISP doing nowadays, instead of charging customer and apply to >> RIPE for their customer's IP, they ask their customer come to RIPE to >> become their own LIR and get their own IP then manage it for the customer. >> In which, results what we see today, shipping companies, banks, even >> airlines become LIR. > Hi, > > This is exactly the point where the community failed. We keep saying > that there is no more IPv4, and in the meanwhile more and more companies > (non-ISP) discover that they can still get their needed IPv4 space, with > the bonus of becoming provider independent. In the process of doing > this, they "eat up" a /22 even if they only need a /23 or a /24 (or > less, but that can't be routed). > > At the same time they still hear (for more than 10 years already) that > IPv6 is coming, but still don't see it "coming close enough" (no, they > don't really care about Google, FB, and Netflix - and if they do, it's > more about how to block them). > From ripe-wgs.cs at schiefner.de Sun Apr 17 23:59:01 2016 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Sun, 17 Apr 2016 23:59:01 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <571080B4.70101@wirem.net> References: <570F9005.4090008@ripe.net> <571080B4.70101@wirem.net> Message-ID: <57140725.7050201@schiefner.de> Riccardo, On 15.04.2016 07:48, Riccardo Gori wrote: > with all respect I don't see a "remarkable success" in current last /8 > policy. > We are dealing with the same amount of space as September 2012 so it works as designed me thinks. > that in the meanwhile has been abused in several ways Please define "abuse in several ways". You are also encouraged to suggest potential remedies per item. > and there are really no incentives to IPv6 adoption. How about: making your Internet outfit future-poof? Sounds pretty convincing to me. Best, -C. From ripe-wgs.cs at schiefner.de Sun Apr 17 23:58:56 2016 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Sun, 17 Apr 2016 23:58:56 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <570F9005.4090008@ripe.net> <20160414125115.GC25856@gir.theapt.org> Message-ID: <57140720.1010203@schiefner.de> On 15.04.2016 00:33, Niall O'Reilly wrote: > On 14 Apr 2016, at 17:01, Jim Reid wrote: > >> I strongly disagree with the proposal > > what Jim said, which you don't need to see again. > Well said, Jim. Ad idem. Best, -C. From arash_mpc at parsun.com Mon Apr 18 04:56:37 2016 From: arash_mpc at parsun.com (Arash Naderpour) Date: Mon, 18 Apr 2016 12:56:37 +1000 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <1460924344.2551496.581389841.14FDECE9@webmail.messagingengine.com> References: <20160415203327.GB31001@danton.fire-world.de> <1460835709.692516.580789321.7E6252B5@webmail.messagingengine.com> <5713329F.9000900@idsys.ro> <20160417083543.GI56633@Space.Net> <1460924344.2551496.581389841.14FDECE9@webmail.messagingengine.com> Message-ID: +1 to this policy. Arash Naderpour On Mon, Apr 18, 2016 at 6:19 AM, Radu-Adrian FEURDEAN < ripe-wgs at radu-adrian.feurdean.net> wrote: > On Sun, Apr 17, 2016, at 10:42, Lu Heng wrote: > > As I understand, more and more end user are becoming LIR as their ISP > > refuse to give them IP, therefore it fundamentally changed the > > very definition of LIR. > > > > The outbreak in the member mailing list last time reminds us how big that > > group could be. > > > > What current ISP doing nowadays, instead of charging customer and apply > to > > RIPE for their customer's IP, they ask their customer come to RIPE to > > become their own LIR and get their own IP then manage it for the > customer. > > In which, results what we see today, shipping companies, banks, even > > airlines become LIR. > > Hi, > > This is exactly the point where the community failed. We keep saying > that there is no more IPv4, and in the meanwhile more and more companies > (non-ISP) discover that they can still get their needed IPv4 space, with > the bonus of becoming provider independent. In the process of doing > this, they "eat up" a /22 even if they only need a /23 or a /24 (or > less, but that can't be routed). > > At the same time they still hear (for more than 10 years already) that > IPv6 is coming, but still don't see it "coming close enough" (no, they > don't really care about Google, FB, and Netflix - and if they do, it's > more about how to block them). > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe-wgs.cs at schiefner.de Mon Apr 18 15:39:08 2016 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Mon, 18 Apr 2016 15:39:08 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <5710AE13.8060201@idsys.ro> References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> Message-ID: <5714E37C.7090908@schiefner.de> Adrian, from my PoV we could start to debate you argument: On 15.04.2016 11:02, Adrian Pitulac wrote: > [...] > > The discussion regarding the last /8 policy benefit can be long, but > from statistics and from my point of view, ARIN depletion of pools, > resulted directly in IPV6 growth. Everyone talks about why RIPE IPv6 > hasn't exploded. I think the reason is IPv4 pools still available. If > market will be constrained by lack of IPv4 pools then IPv6 will explode. if there aren't *ANY* 2nd market IPv4 brokers operating in the ARIN region *AT ALL*. Which AFAIK is not the case. So fulfilling IPv4 address space needs in the North American region should be, give or take, as cheap or expensive, as easy or complicated as anywhere else. So this effect might only be very loosely coupled at best. How about assuming that the US, North America in general, is simply again leading the pack in eventually deploying a not-so-new-any-longer technology? They have done this already in the past, so I have heart. ;-) Best, -C. From reza at admins.ir Mon Apr 18 16:16:50 2016 From: reza at admins.ir (Reza Behroozi) Date: Mon, 18 Apr 2016 18:46:50 +0430 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <5714E37C.7090908@schiefner.de> References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <5714E37C.7090908@schiefner.de> Message-ID: +1 to this policy On Mon, Apr 18, 2016 at 6:09 PM, Carsten Schiefner wrote: > Adrian, > > from my PoV we could start to debate you argument: > > On 15.04.2016 11:02, Adrian Pitulac wrote: > > [...] > > > > The discussion regarding the last /8 policy benefit can be long, but > > from statistics and from my point of view, ARIN depletion of pools, > > resulted directly in IPV6 growth. Everyone talks about why RIPE IPv6 > > hasn't exploded. I think the reason is IPv4 pools still available. If > > market will be constrained by lack of IPv4 pools then IPv6 will explode. > > if there aren't *ANY* 2nd market IPv4 brokers operating in the ARIN > region *AT ALL*. > > Which AFAIK is not the case. > > So fulfilling IPv4 address space needs in the North American region > should be, give or take, as cheap or expensive, as easy or complicated > as anywhere else. > > So this effect might only be very loosely coupled at best. > > How about assuming that the US, North America in general, is simply > again leading the pack in eventually deploying a not-so-new-any-longer > technology? They have done this already in the past, so I have heart. ;-) > > Best, > > -C. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guych at btireland.net Mon Apr 18 16:33:44 2016 From: guych at btireland.net (Guy Chilton) Date: Mon, 18 Apr 2016 15:33:44 +0100 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <570F9005.4090008@ripe.net> References: <570F9005.4090008@ripe.net> Message-ID: <5714F048.5090600@btireland.net> Hello, I've read the proposal and arguments for and against and indeed all the various different opinions presented. Although I can see some merit to support the proposal from a needs based perspective and use of reclaimed addresses. Personally I cannot however ignore the fact that new LIR's into the future will need IPv4 to implement IPv6 based solutions of whatever flavour, and therefore I cannot support this policy change as I believe the current policy is fit for purpose. To confirm I do not support this policy proposal. Kind Regards, Guy On 14/04/2016 13:41, Marco Schmidt wrote: > Dear colleagues, > > The Discussion Period for the policy proposal 2015-05, "Last /8 > Allocation Criteria Revision" has been extended until 13 May 2016. > > The goal of this proposal is to allow LIRs to request an additional /22 > IPv4 allocation from the RIPE NCC every 18 months. > > The text of the proposal has been revised based on mailing list feedback > and we have published a new version (2.0) today. As a result, a new > Discussion Phase has started for the proposal. > > Some of the differences from version 1.0 include: > - Additional /22 IPv4 allocations can be only provided from address > space outside 185/8 > - Only LIRs with less than a /20 in total are eligible to receive > additional allocations > - LIRs must document their IPv6 deployment as part of the request > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2015-05 > > We encourage you to review this policy proposal and send your comments > to . > > Regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC > From rgori at wirem.net Mon Apr 18 17:22:22 2016 From: rgori at wirem.net (Riccardo Gori) Date: Mon, 18 Apr 2016 17:22:22 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <57140725.7050201@schiefner.de> References: <570F9005.4090008@ripe.net> <571080B4.70101@wirem.net> <57140725.7050201@schiefner.de> Message-ID: <5714FBAE.2080105@wirem.net> Hi Carten, Il 17/04/2016 23:59, Carsten Schiefner ha scritto: > Riccardo, > > On 15.04.2016 07:48, Riccardo Gori wrote: >> with all respect I don't see a "remarkable success" in current last /8 >> policy. >> We are dealing with the same amount of space as September 2012 > so it works as designed me thinks. It depends on the point of view, we are discussing this exactly beacause everyone of us can have his point. RIR are supposed to act as a registry and distribute resources. How resources are distributed depends on community. This is exacly why RIR have to accept comments in PDP from non members and from everyone else in the world. What if just a mass of people come here and propose to adopt ARIN similar policy? Policy Development Process is: I would/think; You would/think; He would/think and finally: We do...shouldn't be like that? Resources are global you can't say ARIN was wrong because depleted faster entered and we are successfull just because we still have space. About IPv6 adoption sorry but the fact is that we are later than ARIN. Don't misunderstant please I am not in favor of depletion. > >> that in the meanwhile has been abused in several ways > Please define "abuse in several ways". You are also encouraged to > suggest potential remedies per item. Several ways include repeated and reiterated procedures like these: - cases of LIRs requested and obtained (before 09/2012 and last /8 policy) resources with fake network plans (now you don't need any network plan) - in the past (I mean before 09/2012 and last /8 policy) some organizations running multiple LIR used it to obtaion space as big as /16 on the same day in two different LIRs - in Last /8 multiple LIRs used to obtain resources and sell resources to the market preocess reiterated and (stopped by 2015-01) - open and closing LIR to stockpile resources (stopped by 2015-01) Please note that new allocation rate of /22 from 185/8 reamins unchanged due to new LIR signin up at the same rate or faster. Our policy is suppose to reduce new LIR sign up rate allowing current new entrants to not incentive their customers to sign up as a new LIR and waste a /22 and offer them just the space they need. >> and there are really no incentives to IPv6 adoption. > How about: making your Internet outfit future-poof? Sounds pretty > convincing to me. Carten, as proposers, we didn't pretend to have "the solution". The proposal contains something we believe in and here we tried to push some incentive to adopt IPv6 for smaller LIRs as you can understand from the text. Please read carefully the BOARD consideratios in 2014-04 that removed the only IPv6 requisite on current policy https://www.ripe.net/participate/policies/proposals/2014-04 Now you can get your IPv6 t-shirt as noticed by Radu. About future proof internet: it's easy to say that nothing is future proof but human mind is awsome and when we get in trouble in most cases we were able to find a way out. If it were up to me I would approve NAT in IPv6 and I would use those famouse unusable 16 /8 (for future use 240/8 - 255/8) but this is out of topic here, thank you for asking my point anyway. kind regards Riccardo > > Best, > > -C. -- Ing. Riccardo Gori e-mail: rgori at wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info at wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logoWirem_4cm_conR.jpg Type: image/jpeg Size: 41774 bytes Desc: not available URL: From adrian at idsys.ro Mon Apr 18 17:26:56 2016 From: adrian at idsys.ro (Adrian Pitulac) Date: Mon, 18 Apr 2016 18:26:56 +0300 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <5714E37C.7090908@schiefner.de> References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <5714E37C.7090908@schiefner.de> Message-ID: <5714FCC0.5040502@idsys.ro> > Adrian, > > from my PoV we could start to debate you argument: > > On 15.04.2016 11:02, Adrian Pitulac wrote: >> [...] >> >> The discussion regarding the last /8 policy benefit can be long, but >> from statistics and from my point of view, ARIN depletion of pools, >> resulted directly in IPV6 growth. Everyone talks about why RIPE IPv6 >> hasn't exploded. I think the reason is IPv4 pools still available. If >> market will be constrained by lack of IPv4 pools then IPv6 will explode. > if there aren't *ANY* 2nd market IPv4 brokers operating in the ARIN > region *AT ALL*. > > Which AFAIK is not the case. > > So fulfilling IPv4 address space needs in the North American region > should be, give or take, as cheap or expensive, as easy or complicated > as anywhere else. > > So this effect might only be very loosely coupled at best. > > How about assuming that the US, North America in general, is simply > again leading the pack in eventually deploying a not-so-new-any-longer > technology? They have done this already in the past, so I have heart. ;-) > > Best, > > -C. Even though US/NorthAmerica is again leading the pack deploying IPv6, they had an incentive in IPv4 depletion. On our side, entities do whatever tricks (ex: creating multiple LIR's, even in different countries), to gain access to more IPv4 resources in any way possible. Having a condition like 3 star IPv6 RIPEness to be able to get another IPv4 block each 18 months will provide enough thrust to small entities to enable IPv6 in their networks and this way doing investments also. They will start providing IPv6 services and this way we'll see an objective accomplishment. So, I'm convinced that this policy will fuel IPv6 implementation at a certain level. From swmike at swm.pp.se Mon Apr 18 17:56:18 2016 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 18 Apr 2016 17:56:18 +0200 (CEST) Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <5714FCC0.5040502@idsys.ro> References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <5714E37C.7090908@schiefner.de> <5714FCC0.5040502@idsys.ro> Message-ID: On Mon, 18 Apr 2016, Adrian Pitulac wrote: > Having a condition like 3 star IPv6 RIPEness to be able to get another > IPv4 block each 18 months will provide enough thrust to small entities > to enable IPv6 in their networks and this way doing investments also. > They will start providing IPv6 services and this way we'll see an > objective accomplishment. If you change this to: "Provides IPv6 services by default to all customers who haven't explicitly opted out", I might be tempted to support this policy proposal. However, I think that would put undue burden on RIPE to verify the IPv6 deployment of the LIR in question for them to qualify for another /22 after 18 months. > So, I'm convinced that this policy will fuel IPv6 implementation at a > certain level. Checkboxing 3 star IPv6 RIPEness is easy, unfortunately it has very little to do with real actual widespread IPv6 deployment. -- Mikael Abrahamsson email: swmike at swm.pp.se From adrian at idsys.ro Mon Apr 18 18:14:11 2016 From: adrian at idsys.ro (Adrian Pitulac) Date: Mon, 18 Apr 2016 19:14:11 +0300 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <5714E37C.7090908@schiefner.de> <5714FCC0.5040502@idsys.ro> Message-ID: <571507D3.1000105@idsys.ro> On 18/04/16 18:56, Mikael Abrahamsson wrote: > On Mon, 18 Apr 2016, Adrian Pitulac wrote: > >> Having a condition like 3 star IPv6 RIPEness to be able to get >> another IPv4 block each 18 months will provide enough thrust to small >> entities to enable IPv6 in their networks and this way doing >> investments also. They will start providing IPv6 services and this >> way we'll see an objective accomplishment. > > If you change this to: "Provides IPv6 services by default to all > customers who haven't explicitly opted out", I might be tempted to > support this policy proposal. However, I think that would put undue > burden on RIPE to verify the IPv6 deployment of the LIR in question > for them to qualify for another /22 after 18 months. > >> So, I'm convinced that this policy will fuel IPv6 implementation at a >> certain level. > > Checkboxing 3 star IPv6 RIPEness is easy, unfortunately it has very > little to do with real actual widespread IPv6 deployment. > I'm for changing the policy as needed to make this sustainable and also get real benefit (in terms of IPv6 implementation) from it. This is what I proposed from the start in my interventions here.. Let's discuss and see if we can find a way to gain benefit from this policy. I'm sure that the policy proposers, will look carefully and take into consideration any viable idea. From ripe-wgs at radu-adrian.feurdean.net Mon Apr 18 21:06:27 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Mon, 18 Apr 2016 21:06:27 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <5714E37C.7090908@schiefner.de> <5714FCC0.5040502@idsys.ro> Message-ID: <1461006387.3236565.582432625.1BAF8C7A@webmail.messagingengine.com> On Mon, Apr 18, 2016, at 17:56, Mikael Abrahamsson wrote: > On Mon, 18 Apr 2016, Adrian Pitulac wrote: > > > Having a condition like 3 star IPv6 RIPEness to be able to get another > > IPv4 block each 18 months will provide enough thrust to small entities > > to enable IPv6 in their networks and this way doing investments also. > > They will start providing IPv6 services and this way we'll see an > > objective accomplishment. > > If you change this to: "Provides IPv6 services by default to all customers > who haven't explicitly opted out", I might be tempted to support this > policy proposal. However, I think that would put undue burden on RIPE to > verify the IPv6 deployment of the LIR in question for them to qualify for > another /22 after 18 months. If it can get more support, why not ? 5 stars, why not ? (actually I have some idea why, and it wouldn't bother me) We have already discussed this with NCC staff, things are complex, but any new idea is welcome. From twh at megagroup.ru Tue Apr 19 16:55:44 2016 From: twh at megagroup.ru (Stepan Kucherenko) Date: Tue, 19 Apr 2016 17:55:44 +0300 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <5714E37C.7090908@schiefner.de> <5714FCC0.5040502@idsys.ro> Message-ID: <571646F0.7000508@megagroup.ru> Why not just check for AAAA record for their main site and mention of IPv6 somewhere, like "/X for every customer on every tariff" or something similar depending on the market ? It may put enough pressure for them to actually roll it out. I don't support this proposal in it's current state though. It won't help IPv6 rollout as it is, it can actually make it worse because some LIRs will be able to postpone it even more. But if combined with additional incentives...it might just work. Although ideas of only giving /24 to those who don't need more, and probably just /24 after some arbitrary depletion state (/10?) would be great as well. Anyone writing a policy for that yet ? On 18.04.2016 18:56, Mikael Abrahamsson wrote: > On Mon, 18 Apr 2016, Adrian Pitulac wrote: > >> Having a condition like 3 star IPv6 RIPEness to be able to get another >> IPv4 block each 18 months will provide enough thrust to small entities >> to enable IPv6 in their networks and this way doing investments also. >> They will start providing IPv6 services and this way we'll see an >> objective accomplishment. > > If you change this to: "Provides IPv6 services by default to all > customers who haven't explicitly opted out", I might be tempted to > support this policy proposal. However, I think that would put undue > burden on RIPE to verify the IPv6 deployment of the LIR in question for > them to qualify for another /22 after 18 months. > >> So, I'm convinced that this policy will fuel IPv6 implementation at a >> certain level. > > Checkboxing 3 star IPv6 RIPEness is easy, unfortunately it has very > little to do with real actual widespread IPv6 deployment. > From hph at oslo.net Wed Apr 20 00:01:28 2016 From: hph at oslo.net (Hans Petter Holen) Date: Wed, 20 Apr 2016 00:01:28 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <570F9005.4090008@ripe.net> <20160414125115.GC25856@gir.theapt.org> <1460799072.3821422.580493209.17E86513@webmail.messagingengine.com> <010AD9D5-E830-4A4B-B979-E0EC38A34B01@rfc1035.com> <571234AC.6070108@idsys.ro> <634EA038-17E7-413D-A70A-0B77CDF42173@rfc1035.com> <57125BBC.5050806@idsys.ro> Message-ID: <5716AAB8.7040400@oslo.net> On 16.04.2016 19.00, Jim Reid wrote: > I actually said "This proposal, if adopted, would pretty much guarantee the free pool would not survive 10 months. That is one of the reasons why I oppose it.? If I remember correctly we have spent approx half of the last /8 but the same amount of address space has been returned - so the amount of space available now is approximately the same as when we started the /8 policy. See: https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustion/ipv4-available-pool-graph The complicated part for this wg - is that the charging scheme for RIPE NCC membership is NOT a topic of the wg. At the same time it is very easy to obtain more address space from the RIPE NCC: establish a new registry. This has a cost. While the possibility to establish multiple LIRs pr members has been suspended by the Exec Board, there is an easy workaround - just set up a new company to set up a new registry - but this has a slightly higher cost. This cost is still lower than buying address space on the open market. While restrictions on transfer on address space has been put in place - there are easy workarounds for this as well: sell the company - or make a lease with option to buy agreement. As the RIPE NCC is a membership organization and not a government it will be hard if not impossible to prohibit such workarounds. So the effect of the current policy is that new LIRs are established to get address space. No matter what the policy looks like. Some of this is used for building Internet services - some of this is sold to others to build Internet services. The question for the community is what is fair distribution of address space - now and in the short and long term future. Long term the only viable solution is IPv6 - but how do we share the common good in the mean time? -- Hans Petter Holen Mobile +47 45 06 60 54 | hph at oslo.net | http://hph.oslo.net From hph at oslo.net Wed Apr 20 00:11:07 2016 From: hph at oslo.net (Hans Petter Holen) Date: Wed, 20 Apr 2016 00:11:07 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <6186DAFC-20C1-4CEC-B027-F16518749004@rfc1035.com> References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <6186DAFC-20C1-4CEC-B027-F16518749004@rfc1035.com> Message-ID: <5716ACFB.8040802@oslo.net> On 14.04.2016 18.13, Jim Reid wrote: >> I know companies who've done this. It isn't sensible. > True. But the NCC has ways to deal with those sorts of bad actors. Besides, the checks on a new LIR raise a reasonably high barrier for those who try to game the system in this way. > No. I work for a multi-national corporation. We have multiple datacentres in multiple countries and these are organized as separate legal entities and have separate LIRs. This has been the practice of large multi-national LIRs for the last 20 years. I do not see how that makes us a bad actor gaming the system. -- Hans Petter Holen Mobile +47 45 06 60 54 | hph at oslo.net | http://hph.oslo.net From hph at oslo.net Wed Apr 20 00:21:34 2016 From: hph at oslo.net (Hans Petter Holen) Date: Wed, 20 Apr 2016 00:21:34 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <57113A0D.7020704@idsys.ro> References: <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <4DF65647-8E27-4B62-805A-BFBB79C3B895@ecs.soton.ac.uk> <5710EDAD.2000406@idsys.ro> <571117E6.6050907@idsys.ro> <57112464.7020103@i-net.bg> <20160415182359.GA56633@Space.Net> <57113A0D.7020704@idsys.ro> Message-ID: <5716AF6E.2040101@oslo.net> On 15.04.2016 20.59, Adrian Pitulac wrote: > I'm more inclining to believe that certain old LIR's made a big > business from this, by creating an artificial market and then sold > their free ip pools on the market for a hefty profit. I do not think this is the case. What I see is that old LIRs holding address space they no longer use, because they are not providing internet services, sell it when they realize it has a value. In many cases address space brokers make an effort tracing down unused space and puts it to use. I also see new LIRs beeing set up to sell the space for profit. -- Hans Petter Holen Mobile +47 45 06 60 54 | hph at oslo.net | http://hph.oslo.net From hph at oslo.net Wed Apr 20 00:39:18 2016 From: hph at oslo.net (Hans Petter Holen) Date: Wed, 20 Apr 2016 00:39:18 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <571368CE.3030906@foobar.org> References: <5710AE13.8060201@idsys.ro> <5710EDAD.2000406@idsys.ro> <571117E6.6050907@idsys.ro> <57112464.7020103@i-net.bg> <20160415182359.GA56633@Space.Net> <57113A0D.7020704@idsys.ro> <20160415203327.GB31001@danton.fire-world.de> <1460835709.692516.580789321.7E6252B5@webmail.messagingengine.com> <79E87D21-FECD-4C1E-B11F-F193719E5B25@consulintel.es> <571368CE.3030906@foobar.org> Message-ID: <5716B396.7090200@oslo.net> On 17.04.2016 12.43, Nick Hilliard wrote: > JORDI PALET MARTINEZ wrote: >> 5) No new IPv4 policies. > As much as this might seem like a good idea for stopping the endless > arguments about changing the last /8 allocation policy, the only thing > which will actually put and end to these arguments is final depletion. > Everything else is deck-chair rearrangement. I think this is a very good point. While we say that the community is much larger than the RIPE NCC membership, the RIPE NCC membership, which is part of the community, is much larger than this working-group. With the current growth rate of RIPE NCC membership - the community grows - and the opinion on what is the best policy is changing. What was discussed yesterday may not be as valid tomorrow. Keeping the registry up to date - with correct information - will always be top priority. Lets make sure we do not have policies that affects this. -- Hans Petter Holen Mobile +47 45 06 60 54 | hph at oslo.net | http://hph.oslo.net From h.lu at anytimechinese.com Wed Apr 20 00:47:11 2016 From: h.lu at anytimechinese.com (Lu Heng) Date: Wed, 20 Apr 2016 06:47:11 +0800 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <5716AAB8.7040400@oslo.net> References: <570F9005.4090008@ripe.net> <20160414125115.GC25856@gir.theapt.org> <1460799072.3821422.580493209.17E86513@webmail.messagingengine.com> <010AD9D5-E830-4A4B-B979-E0EC38A34B01@rfc1035.com> <571234AC.6070108@idsys.ro> <634EA038-17E7-413D-A70A-0B77CDF42173@rfc1035.com> <57125BBC.5050806@idsys.ro> <5716AAB8.7040400@oslo.net> Message-ID: Hi On Wednesday 20 April 2016, Hans Petter Holen wrote: > On 16.04.2016 19.00, Jim Reid wrote: > >> I actually said "This proposal, if adopted, would pretty much guarantee >> the free pool would not survive 10 months. That is one of the reasons why I >> oppose it.? >> > If I remember correctly we have spent approx half of the last /8 > but the same amount of address space has been returned - so the amount of > space available now is approximately the same as when we started the /8 > policy. > See: > https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustion/ipv4-available-pool-graph > > The complicated part for this wg - is that the charging scheme for RIPE > NCC membership is NOT a topic of the wg. > > At the same time it is very easy to obtain more address space from the > RIPE NCC: establish a new registry. This has a cost. While the possibility > to establish multiple LIRs pr members has been suspended by the Exec Board, > there is an easy workaround - just set up a new company to set up a new > registry - but this has a slightly higher cost. This cost is still lower > than buying address space on the open market. While restrictions on > transfer on address space has been put in place - there are easy > workarounds for this as well: sell the company - or make a lease with > option to buy agreement. > > As the RIPE NCC is a membership organization and not a government it will > be hard if not impossible to prohibit such workarounds. > > Can not agree more. Folks here barely thinking about the "business" side of the story, if there is an way to make profit and no risk, people would do it. With raising v4 price, I would expect much faster depletion due to the very fact that paying RIPE NCC is easier, more transparent in the process compare to the market, and even cheaper. > So the effect of the current policy is that new LIRs are established to > get address space. No matter what the policy looks like. Some of this is > used for building Internet services - some of this is sold to others to > build Internet services. > > The question for the community is what is fair distribution of address > space - now and in the short and long term future. > > Long term the only viable solution is IPv6 - but how do we share the > common good in the mean time? > > -- > Hans Petter Holen > Mobile +47 45 06 60 54 | hph at oslo.net | http://hph.oslo.net > > > -- -- Kind regards. Lu -------------- next part -------------- An HTML attachment was scrubbed... URL: From hph at oslo.net Wed Apr 20 00:52:02 2016 From: hph at oslo.net (Hans Petter Holen) Date: Wed, 20 Apr 2016 00:52:02 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <002301d19689$48432160$d8c96420$@a2b-internet.com> References: <570F9005.4090008@ripe.net> <002301d19689$48432160$d8c96420$@a2b-internet.com> Message-ID: <5716B692.4060909@oslo.net> On 14.04.2016 22.07, Erik Bais wrote: > but the difference is an issue of fully running out within 18 months or 5.3 years. Thanks for a very useful analysis Erik. I think this is the key point - does the community want to put priority short term or longer term? -- Hans Petter Holen Mobile +47 45 06 60 54 | hph at oslo.net | http://hph.oslo.net From hph at oslo.net Wed Apr 20 00:53:53 2016 From: hph at oslo.net (Hans Petter Holen) Date: Wed, 20 Apr 2016 00:53:53 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <570F9005.4090008@ripe.net> Message-ID: <5716B701.1030305@oslo.net> On 15.04.2016 00.50, remco van mook wrote: > a few obvious loopholes that are now being used to contravene the > intention of the policy, I would be interested to see how this can be done effectively. As a matter of transparency I think it is important to understand all the aspects of this. The policy does not exist in a vacuum. -- Hans Petter Holen Mobile +47 45 06 60 54 | hph at oslo.net | http://hph.oslo.net From hph at oslo.net Wed Apr 20 01:17:24 2016 From: hph at oslo.net (Hans Petter Holen) Date: Wed, 20 Apr 2016 01:17:24 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <57121420.6614c20a.ebfb5.4312@mx.google.com> References: <57121420.6614c20a.ebfb5.4312@mx.google.com> Message-ID: <5716BC84.2010406@oslo.net> An HTML attachment was scrubbed... URL: From jim at rfc1035.com Wed Apr 20 01:46:19 2016 From: jim at rfc1035.com (Jim Reid) Date: Wed, 20 Apr 2016 00:46:19 +0100 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <5716ACFB.8040802@oslo.net> References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <6186DAFC-20C1-4CEC-B027-F16518749004@rfc1035.com> <5716ACFB.8040802@oslo.net> Message-ID: <44999850-3BB2-47D1-96FB-42A4A21A5248@rfc1035.com> > On 19 Apr 2016, at 23:11, Hans Petter Holen wrote: > > On 14.04.2016 18.13, Jim Reid wrote: >>> I know companies who've done this. It isn't sensible. >> True. But the NCC has ways to deal with those sorts of bad actors. Besides, the checks on a new LIR raise a reasonably high barrier for those who try to game the system in this way. >> > No. > I work for a multi-national corporation. We have multiple datacentres in multiple countries and these are organized as separate legal entities and have separate LIRs. This has been the practice of large multi-national LIRs for the last 20 years. > > I do not see how that makes us a bad actor gaming the system. I do not see that either Hans Petter. Or how anyone might consider that sort of behaviour to be a bad actor gaming the system. As I?m sure you know, when an application for a new LIR is made, paperwork -- certificates of incorporation, tax registration numbers, contact details and so on -- has to be supplied to the NCC. This information gets checked. Those checks by the NCC are (or should be) strong enough to weed out membership applications by bad actors. Which presumably would not include the sort of good faith activity you described above. Bad actors may well try to become an LIR to get address space ?for free? from the NCC. But they'll first have to set up a legal entity, register it with the national tax authorities and chamber of commerce, pay a lawyer or accountant, etc, etc. The cost of all that effort plus the NCC fees is very likely to be similar to the value of their exactly one /22 on the secondary market. IMO these factors do raise barriers which should make it harder for an impostor to game the system without unduly inconveniencing genuine applicants. That?s what I was saying earlier. Now there are ways to game address allocation. [There always have and probably always will.] You even mentioned some. It?s dpoubtful these sorts of activities would go unnoticed. And at the very least questions would (or should) be asked to establish if these actions were carried out in good faith or were something more suspicious than that. Note too that I was not saying or implying that everyone who sets up an LIR to get a /22 -- or LIRs to get >1 /22 -- is a bad actor. Some wannabe LIRs might be up to no good. That?s just a fact of life: there?s always someone somewhere trying to break or bend the rules. But I trust the NCC?s checks are robust enough to identify these impostors and deal with them. Further discussion about that should probably take place at the (A)GM and not on this list. From jim at rfc1035.com Wed Apr 20 02:02:31 2016 From: jim at rfc1035.com (Jim Reid) Date: Wed, 20 Apr 2016 01:02:31 +0100 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <5716AF6E.2040101@oslo.net> References: <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <4DF65647-8E27-4B62-805A-BFBB79C3B895@ecs.soton.ac.uk> <5710EDAD.2000406@idsys.ro> <571117E6.6050907@idsys.ro> <57112464.7020103@i-net.bg> <20160415182359.GA56633@Space.Net> <57113A0D.7020704@idsys.ro> <5716AF6E.2040101@oslo.net> Message-ID: > On 19 Apr 2016, at 23:21, Hans Petter Holen wrote: > > I also see new LIRs beeing set up to sell the space for profit. That?s regrettable and I wish it stopped. [Well it will when we run out of v4... :-)] But if we could stop this, I suppose those ?bad actors? would just acquire space on the secondary market or other sources and that could harm the quality of the info in the RIPE database. Both choices are ugly. From rgori at wirem.net Wed Apr 20 08:37:42 2016 From: rgori at wirem.net (Riccardo Gori) Date: Wed, 20 Apr 2016 08:37:42 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <5716BC84.2010406@oslo.net> References: <57121420.6614c20a.ebfb5.4312@mx.google.com> <5716BC84.2010406@oslo.net> Message-ID: <571723B6.1060508@wirem.net> Hi Hans, good morning list, I think there is no confusion. section 5.3 https://www.ripe.net/publications/docs/ripe-649 [...] 5.3 Address Recycling Any address space that is returned to the RIPE NCC will be covered by the same rules as the address space intended in section 5.1. This section only applies to address space that is returned to the RIPE NCC and that will not be returned to the IANA but re-issued by the RIPE NCC itself. [...] What is you understanding of "not be returned to the IANA but re-issued by the RIPE NCC itself" ? In my understanding this does not talks about any space RECEIVED from IANA's Recovered IPv4 Pool Recovered space reiceved from IANA comes from a global policy ratified by RIRs in September 2012 Maybe Andrea Cima can clarify RIPE NCC understanding about this, Andrea could you please give us RIPE NCC understading? On the other hand it's easy to say that all the available pool can fall under the same policy in section 5.1. but it's clear that when last /8 was thought was to allow new entrants as well as existing LIRs develop IPv6 and keep fairness on the market. Sorry for repeating myself but please note that policy 2014-04 (https://www.ripe.net/participate/policies/proposals/2014-04) removed IPv6 requirement to obtain last /22 IPv4 allocation. We have no IPv6 incentives but t-shirts! Gert, Sander (Chairs): may I ask you to give me/us your opinion about absence of IPv6 incetives in our policies don't you think we are missing something? regards Riccardo Il 20/04/2016 01:17, Hans Petter Holen ha scritto: > On 16.04.2016 12.29, remco.vanmook at gmail.com wrote: >> This confusion has been haunting the final /8 policy from day one - >> it was never about what to do with specifically 185/8, but what to do >> with all future allocations from the moment we needed to start >> allocating out of it. The policy text itself was never limited to a >> single /8, nor was that limitation any part of the discussion. > > I looked up the policy proposal at > https://www.ripe.net/participate/policies/proposals/2010-02 > > " This proposal describes how the RIPE NCC should distribute IPv4 > address space from the final /8 address block it receives from the IANA." > > Reading the rest of the proposal I fully understand the confusion and > find it hard to read your interpretation into the proposal. > > The updated policy after this proposal can be found in RIPE 509 > https://www.ripe.net/publications/docs/ripe-509#----use-of-last----for-pa-allocations > * The following policies come into effect as soon as RIPE NCC is > required to make allocations from the final /8 it receives from the IANA. > > It does not discuss the event where RIPE NCC gets more address space > and could allocate from - which would strictly speaking not be > allocation from the last /8 > > Tracing the policy text trough the versions - This text was first > removed between > * RIPE 599 published on 20 December 2013 > https://www.ripe.net/publications/docs/ripe-599#Use-last-for-PA-Allocationsand > * RIPE 604 - published on 4 Feb 2014: > https://www.ripe.net/publications/docs/ripe-604 > > Where the text was changed to: > > 1. The size of the allocation made will be exactly one /22. > 2. The sum of all allocations made to a single LIR by the RIPE NCC > after the 14th of September 2012 is limited to a maximum of 1024 > IPv4 addresses (a single /22 or the equivalent thereof). > > and no reference to the last /8. > > So I can easily understand the confusion. > > -- > Hans Petter Holen > Mobile +47 45 06 60 54 |hph at oslo.net |http://hph.oslo.net > -- Ing. Riccardo Gori e-mail: rgori at wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info at wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logoWirem_4cm_conR.jpg Type: image/jpeg Size: 41774 bytes Desc: not available URL: From rgori at wirem.net Wed Apr 20 09:17:02 2016 From: rgori at wirem.net (Riccardo Gori) Date: Wed, 20 Apr 2016 09:17:02 +0200 Subject: [address-policy-wg] trouble with email client repreated messages Message-ID: <57172CEE.4040600@wirem.net> Please list consider only my last message of repeated ones about "Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision)" I am getting in trouble with my email client and seems to send sort of draft revision of messages wich I didn't even saved as draft on it. It's second time happens and I didn't realize how. I am just replying normally and leaving opened on my pc the the draft and while waiting it seems to send 5 minutes time revision to list. Sorry I am using Thunderbird 38.7.2 and I was not aware of this kind of problem. I will change/update it as soon as possible. Sorry, It's happing out of my control. regards Riccardo -- Ing. Riccardo Gori e-mail: rgori at wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info at wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logoWirem_4cm_conR.jpg Type: image/jpeg Size: 41774 bytes Desc: not available URL: From hph at oslo.net Wed Apr 20 10:17:20 2016 From: hph at oslo.net (Hans Petter Holen) Date: Wed, 20 Apr 2016 10:17:20 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <571723B6.1060508@wirem.net> References: <57121420.6614c20a.ebfb5.4312@mx.google.com> <5716BC84.2010406@oslo.net> <571723B6.1060508@wirem.net> Message-ID: <57173B10.7090207@oslo.net> On 20/04/16 08:37, Riccardo Gori wrote: > > I think there is no confusion. > section 5.3 https://www.ripe.net/publications/docs/ripe-649 Yes - I agree that there should be no confusion on the current policy text. I commented on Remcos statement: On 16.04.2016 12.29, remco.vanmook at gmail.com wrote: > This confusion has been haunting the final /8 policy from day one - it > was never about what to do with specifically 185/8, but what to do > with all future allocations from the moment we needed to start > allocating out of it. The policy text itself was never limited to a > single /8, nor was that limitation any part of the discussion. And as far as I has been able to establish it was not that clear - to me - from the text in the original proposal. So while it is clear today - it was not clear to me that it was "from day one" - as Remco stated. As far as I can see the language you refer to was introduced in RIPE 530 on 21 Oct 2011. https://www.ripe.net/publications/docs/ripe-530 The reason I point out this is that we should not use the past as an argument for the future - but have an open discussion on whats best for the future. And if we refer to the past it should > > [...] > 5.3 Address Recycling > Any address space that is returned to the RIPE NCC will be covered by > the same rules as the address space intended in section 5.1. > This section only applies to address space that is returned to the > RIPE NCC and that will not be returned to the IANA but re-issued by > the RIPE NCC itself. > [...] > > What is you understanding of "not be returned to the IANA but > re-issued by the RIPE NCC itself" ? Address space recovered by the RIPE NCC and not returned to IANA. The other two categories is address space from IANA and the last /8. My understanding is that the current practice under curent policy is to threat all 3 categories the same. From RIPE 530 on 21 Oct 21 going forward. Hans Petter -------------- next part -------------- An HTML attachment was scrubbed... URL: From rogerj at gmail.com Wed Apr 20 10:36:10 2016 From: rogerj at gmail.com (=?UTF-8?Q?Roger_J=C3=B8rgensen?=) Date: Wed, 20 Apr 2016 10:36:10 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <1461006387.3236565.582432625.1BAF8C7A@webmail.messagingengine.com> References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <5714E37C.7090908@schiefner.de> <5714FCC0.5040502@idsys.ro> <1461006387.3236565.582432625.1BAF8C7A@webmail.messagingengine.com> Message-ID: On Mon, Apr 18, 2016 at 9:06 PM, Radu-Adrian FEURDEAN wrote: > If it can get more support, why not ? > 5 stars, why not ? (actually I have some idea why, and it wouldn't > bother me) To me it seems like there are a not so minor misunderstanding right here. It is not so much about getting MORE support, since we do not vote. What we do are working toward a overall good solution. Unfortunately there are no real good solution, our only option is to change protocol, and with that change some pain will follow which it seems like you and other are experience. Embrace the future, don't run from it and avoid facing it, that is my suggestion. The current policy is there to keep some space in reserve for future startups so they can have _some_ IPv4 space for whatever reason, it is NOT there to give current startups enough IPv4 space, that is just not possible. All pools are either empty or they are running out, and due to ongoing cleanup we are so lucky that there has been IPv4 space returned so the runout will take longer, that is we have _some_ IPv4 space longer than we initial thought was possible! Let us not waste that with being greedy here and now. The only IPv4 left are what can be found from redistribution or splitting up of already allocated IPv4 space, that has it's own ballpark of trouble associated with it, an entire different discussion. -- Roger Jorgensen | ROJO9-RIPE rogerj at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From rogerj at gmail.com Wed Apr 20 11:00:25 2016 From: rogerj at gmail.com (=?UTF-8?Q?Roger_J=C3=B8rgensen?=) Date: Wed, 20 Apr 2016 11:00:25 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <5716BC84.2010406@oslo.net> References: <57121420.6614c20a.ebfb5.4312@mx.google.com> <5716BC84.2010406@oslo.net> Message-ID: On Wed, Apr 20, 2016 at 1:17 AM, Hans Petter Holen wrote: > On 16.04.2016 12.29, remco.vanmook at gmail.com wrote: >> This confusion has been haunting the final /8 policy from day one - it was >> never about what to do with specifically 185/8, but what to do with all >> future allocations from the moment we needed to start allocating out of it. >> The policy text itself was never limited to a single /8, nor was that >> limitation any part of the discussion. It was a name for the point in time when it would be activated, and it would stay there until there was no IPv4 left to hand out. > I looked up the policy proposal at > https://www.ripe.net/participate/policies/proposals/2010-02 > > " This proposal describes how the RIPE NCC should distribute IPv4 address > space from the final /8 address block it receives from the IANA." Not the best wording back there it seems... > Reading the rest of the proposal I fully understand the confusion and find > it hard to read your interpretation into the proposal. > > The updated policy after this proposal can be found in RIPE 509 > https://www.ripe.net/publications/docs/ripe-509#----use-of-last----for-pa-allocations > * The following policies come into effect as soon as RIPE NCC is required to > make allocations from the final /8 it receives from the IANA. > > It does not discuss the event where RIPE NCC gets more address space and > could allocate from - which would strictly speaking not be allocation from > the last /8 somewhere along the way, I think, but haven't found it yet, it was said that this policy would get activated when they got the last /8 from IANA, that was the intention. Whatever happend after _that_ point in time, would be covered by that policy. That part was to cover what you mention next... > Tracing the policy text trough the versions - This text was first removed > between > * RIPE 599 published on 20 December 2013 > https://www.ripe.net/publications/docs/ripe-599#Use-last-for-PA-Allocations > and > * RIPE 604 - published on 4 Feb 2014: > https://www.ripe.net/publications/docs/ripe-604 > > Where the text was changed to: > > The size of the allocation made will be exactly one /22. > The sum of all allocations made to a single LIR by the RIPE NCC after the > 14th of September 2012 is limited to a maximum of 1024 IPv4 addresses (a > single /22 or the equivalent thereof). The side story behind this is probably related to that it was assumed that IANA would get some address space back, address space they again could redistribute to the LIR. When slized up it would at some point not be possible to hand out /22's, only smaller blocks that could add upto a /22. All that would be addresses covered by "the last /8 policy", the runout policy. > and no reference to the last /8. > > So I can easily understand the confusion. The intention was that once the policy was activated it would be there for all future until there was no IPv4 left. It was just called "the last /8 policy" since that's how it started out, the activation point. (I can't find referenced to all of this but it is somewhere in the archives, and guess Geert or you can find it all? Wonder if it might be somewhere in the IETF space or so this was discussed to?) -- Roger Jorgensen | ROJO9-RIPE rogerj at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From rgori at wirem.net Wed Apr 20 11:53:18 2016 From: rgori at wirem.net (Riccardo Gori) Date: Wed, 20 Apr 2016 11:53:18 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <57121420.6614c20a.ebfb5.4312@mx.google.com> <5716BC84.2010406@oslo.net> Message-ID: <5717518E.70409@wirem.net> Hi Roger, Il 20/04/2016 11:00, Roger J?rgensen ha scritto: > On Wed, Apr 20, 2016 at 1:17 AM, Hans Petter Holen wrote: >> On 16.04.2016 12.29, remco.vanmook at gmail.com wrote: >>> This confusion has been haunting the final /8 policy from day one - it was >>> never about what to do with specifically 185/8, but what to do with all >>> future allocations from the moment we needed to start allocating out of it. >>> The policy text itself was never limited to a single /8, nor was that >>> limitation any part of the discussion. > It was a name for the point in time when it would be activated, and it would > stay there until there was no IPv4 left to hand out. > > >> I looked up the policy proposal at >> https://www.ripe.net/participate/policies/proposals/2010-02 >> >> " This proposal describes how the RIPE NCC should distribute IPv4 address >> space from the final /8 address block it receives from the IANA." > Not the best wording back there it seems... > > >> Reading the rest of the proposal I fully understand the confusion and find >> it hard to read your interpretation into the proposal. >> >> The updated policy after this proposal can be found in RIPE 509 >> https://www.ripe.net/publications/docs/ripe-509#----use-of-last----for-pa-allocations >> * The following policies come into effect as soon as RIPE NCC is required to >> make allocations from the final /8 it receives from the IANA. >> >> It does not discuss the event where RIPE NCC gets more address space and >> could allocate from - which would strictly speaking not be allocation from >> the last /8 > somewhere along the way, I think, but haven't found it yet, it was > said that this > policy would get activated when they got the last /8 from IANA, that was the > intention. Whatever happend after _that_ point in time, would be covered by > that policy. That part was to cover what you mention next... Are you sure? I mean, when 185/8 has been reiceved from IANA: There was some space around left on the free pool and it has been allocated under the same "last /8 policy" from that moment or followed its own old path? I am serius since I wasn't here at that time and I don't really know what happened. Andrea, can you help me understand what happened to available pool is any when 185/8 was reiceved by IANA? please understand I signed up 01/2015, when exacly took place the first allocation made under "last /8" policy? any help would be appreciated thanks Riccardo > > >> Tracing the policy text trough the versions - This text was first removed >> between >> * RIPE 599 published on 20 December 2013 >> https://www.ripe.net/publications/docs/ripe-599#Use-last-for-PA-Allocations >> and >> * RIPE 604 - published on 4 Feb 2014: >> https://www.ripe.net/publications/docs/ripe-604 >> >> Where the text was changed to: >> >> The size of the allocation made will be exactly one /22. >> The sum of all allocations made to a single LIR by the RIPE NCC after the >> 14th of September 2012 is limited to a maximum of 1024 IPv4 addresses (a >> single /22 or the equivalent thereof). > The side story behind this is probably related to that it was assumed that > IANA would get some address space back, address space they again could > redistribute to the LIR. When slized up it would at some point not be possible > to hand out /22's, only smaller blocks that could add upto a /22. > All that would be addresses covered by "the last /8 policy", the runout policy. > > >> and no reference to the last /8. >> >> So I can easily understand the confusion. > The intention was that once the policy was activated it would be there for all > future until there was no IPv4 left. It was just called "the last /8 policy" > since that's how it started out, the activation point. > > > > (I can't find referenced to all of this but it is somewhere in the archives, and > guess Geert or you can find it all? Wonder if it might be somewhere in the > IETF space or so this was discussed to?) > -- Ing. Riccardo Gori e-mail: rgori at wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info at wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logoWirem_4cm_conR.jpg Type: image/jpeg Size: 41774 bytes Desc: not available URL: From ingrid at ripe.net Wed Apr 20 12:09:09 2016 From: ingrid at ripe.net (Ingrid Wijte) Date: Wed, 20 Apr 2016 12:09:09 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <5717518E.70409@wirem.net> References: <57121420.6614c20a.ebfb5.4312@mx.google.com> <5716BC84.2010406@oslo.net> <5717518E.70409@wirem.net> Message-ID: <57175545.1060205@ripe.net> Dear Riccardo, (I am responding on behalf of Andrea, who is currently traveling). We just wanted to confirm that Hans Petter and Roger are correct. The policy text you quoted was designed to allow address space to be returned to IANA. It does not refer to the way that the RIPE NCC should allocate from our available IPv4 pool. With the current policy, the RIPE NCC does not distinguish between address space in our available IPv4 pool on the basis of where it came from. We are currently allocating from 185/8 mainly for simplicity, and to allow a long quarantine period for returned address space. The RIPE NCC started to allocate from 185/8 on 14 September 2012, when we could no longer satisfy a request for address space without touching 185/8. That moment triggered section 5.1 that states that RIPE NCC members can request a one time /22 allocation (1,024 IPv4 addresses). I hope this helps. Best regards, Ingrid Wijte Assistant Manager Registration Services RIPE NCC On 20/04/2016 11:53, Riccardo Gori wrote: > Hi Roger, > > Il 20/04/2016 11:00, Roger J?rgensen ha scritto: >> On Wed, Apr 20, 2016 at 1:17 AM, Hans Petter Holen wrote: >>> On 16.04.2016 12.29,remco.vanmook at gmail.com wrote: >>>> This confusion has been haunting the final /8 policy from day one - it was >>>> never about what to do with specifically 185/8, but what to do with all >>>> future allocations from the moment we needed to start allocating out of it. >>>> The policy text itself was never limited to a single /8, nor was that >>>> limitation any part of the discussion. >> It was a name for the point in time when it would be activated, and it would >> stay there until there was no IPv4 left to hand out. >> >> >>> I looked up the policy proposal at >>> https://www.ripe.net/participate/policies/proposals/2010-02 >>> >>> " This proposal describes how the RIPE NCC should distribute IPv4 address >>> space from the final /8 address block it receives from the IANA." >> Not the best wording back there it seems... >> >> >>> Reading the rest of the proposal I fully understand the confusion and find >>> it hard to read your interpretation into the proposal. >>> >>> The updated policy after this proposal can be found in RIPE 509 >>> https://www.ripe.net/publications/docs/ripe-509#----use-of-last----for-pa-allocations >>> * The following policies come into effect as soon as RIPE NCC is required to >>> make allocations from the final /8 it receives from the IANA. >>> >>> It does not discuss the event where RIPE NCC gets more address space and >>> could allocate from - which would strictly speaking not be allocation from >>> the last /8 >> somewhere along the way, I think, but haven't found it yet, it was >> said that this >> policy would get activated when they got the last /8 from IANA, that was the >> intention. Whatever happend after _that_ point in time, would be covered by >> that policy. That part was to cover what you mention next... > > Are you sure? I mean, when 185/8 has been reiceved from IANA: > There was some space around left on the free pool and it has been > allocated under the same "last /8 policy" from that moment or followed > its own old path? > I am serius since I wasn't here at that time and I don't really know > what happened. > Andrea, can you help me understand what happened to available pool is > any when 185/8 was reiceved by IANA? > please understand I signed up 01/2015, when exacly took place the > first allocation made under "last /8" policy? > any help would be appreciated > thanks > Riccardo > >> >>> Tracing the policy text trough the versions - This text was first removed >>> between >>> * RIPE 599 published on 20 December 2013 >>> https://www.ripe.net/publications/docs/ripe-599#Use-last-for-PA-Allocations >>> and >>> * RIPE 604 - published on 4 Feb 2014: >>> https://www.ripe.net/publications/docs/ripe-604 >>> >>> Where the text was changed to: >>> >>> The size of the allocation made will be exactly one /22. >>> The sum of all allocations made to a single LIR by the RIPE NCC after the >>> 14th of September 2012 is limited to a maximum of 1024 IPv4 addresses (a >>> single /22 or the equivalent thereof). >> The side story behind this is probably related to that it was assumed that >> IANA would get some address space back, address space they again could >> redistribute to the LIR. When slized up it would at some point not be possible >> to hand out /22's, only smaller blocks that could add upto a /22. >> All that would be addresses covered by "the last /8 policy", the runout policy. >> >> >>> and no reference to the last /8. >>> >>> So I can easily understand the confusion. >> The intention was that once the policy was activated it would be there for all >> future until there was no IPv4 left. It was just called "the last /8 policy" >> since that's how it started out, the activation point. >> >> >> >> (I can't find referenced to all of this but it is somewhere in the archives, and >> guess Geert or you can find it all? Wonder if it might be somewhere in the >> IETF space or so this was discussed to?) >> > > -- > Ing. Riccardo Gori > e-mail:rgori at wirem.net > Mobile: +39 339 8925947 > Mobile: +34 602 009 437 > Profile:https://it.linkedin.com/in/riccardo-gori-74201943 > WIREM Fiber Revolution > Net-IT s.r.l. > Via Cesare Montanari, 2 > 47521 Cesena (FC) > Tel +39 0547 1955485 > Fax +39 0547 1950285 > > -------------------------------------------------------------------- > CONFIDENTIALITY NOTICE > This message and its attachments are addressed solely to the persons > above and may contain confidential information. If you have received > the message in error, be informed that any use of the content hereof > is prohibited. Please return it immediately to the sender and delete > the message. Should you have any questions, please contact us by re- > plying toinfo at wirem.net > Thank you > WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) > -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 41774 bytes Desc: not available URL: From niall.oreilly at ucd.ie Wed Apr 20 12:50:27 2016 From: niall.oreilly at ucd.ie (Niall O'Reilly) Date: Wed, 20 Apr 2016 11:50:27 +0100 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <5717518E.70409@wirem.net> References: <57121420.6614c20a.ebfb5.4312@mx.google.com> <5716BC84.2010406@oslo.net> <5717518E.70409@wirem.net> Message-ID: <9B0EE8AA-81E3-4060-9DDA-E835C395E631@ucd.ie> On 20 Apr 2016, at 10:53, Riccardo Gori wrote: > Andrea, can you help me understand what happened to available pool is > any when 185/8 was reiceved by IANA? I think this may be the wrong question. IIRC, the triggering of the "last /8" policy (as it has usually been known) did not coincide with receipt of 185/8 from (NB: not "by") IANA by RIPE NCC, but rather with the first allocation by RIPE NCC from 185/8. As Roger J?rgensen has explained, once the policy was triggered, it was to apply to all subsequent allocations. Best regards, Niall O'Reilly From rgori at wirem.net Wed Apr 20 13:02:20 2016 From: rgori at wirem.net (Riccardo Gori) Date: Wed, 20 Apr 2016 13:02:20 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <57175545.1060205@ripe.net> References: <57121420.6614c20a.ebfb5.4312@mx.google.com> <5716BC84.2010406@oslo.net> <5717518E.70409@wirem.net> <57175545.1060205@ripe.net> Message-ID: <571761BC.4040902@wirem.net> Dear Ingrid, thank you for you help Il 20/04/2016 12:09, Ingrid Wijte ha scritto: > Dear Riccardo, > > (I am responding on behalf of Andrea, who is currently traveling). > > We just wanted to confirm that Hans Petter and Roger are correct. The > policy text you quoted was designed to allow address space to be > returned to IANA. It does not refer to the way that the RIPE NCC > should allocate from our available IPv4 pool. > > With the current policy, the RIPE NCC does not distinguish between > address space in our available IPv4 pool on the basis of where it came > from. We are currently allocating from 185/8 mainly for simplicity, > and to allow a long quarantine period for returned address space. > The RIPE NCC started to allocate from 185/8 on 14 September 2012, when > we could no longer satisfy a request for address space without > touching 185/8. That moment triggered section 5.1 that states that > RIPE NCC members can request a one time /22 allocation (1,024 IPv4 > addresses). Thank you, I'll try to understand as best as possibile how it worked/works but I am quite new so I don't know very well history things. > I hope this helps. thank you for your help Riccardo > > Best regards, > > Ingrid Wijte > Assistant Manager Registration Services > RIPE NCC > > On 20/04/2016 11:53, Riccardo Gori wrote: >> Hi Roger, >> >> Il 20/04/2016 11:00, Roger J?rgensen ha scritto: >>> On Wed, Apr 20, 2016 at 1:17 AM, Hans Petter Holen wrote: >>>> On 16.04.2016 12.29,remco.vanmook at gmail.com wrote: >>>>> This confusion has been haunting the final /8 policy from day one - it was >>>>> never about what to do with specifically 185/8, but what to do with all >>>>> future allocations from the moment we needed to start allocating out of it. >>>>> The policy text itself was never limited to a single /8, nor was that >>>>> limitation any part of the discussion. >>> It was a name for the point in time when it would be activated, and it would >>> stay there until there was no IPv4 left to hand out. >>> >>> >>>> I looked up the policy proposal at >>>> https://www.ripe.net/participate/policies/proposals/2010-02 >>>> >>>> " This proposal describes how the RIPE NCC should distribute IPv4 address >>>> space from the final /8 address block it receives from the IANA." >>> Not the best wording back there it seems... >>> >>> >>>> Reading the rest of the proposal I fully understand the confusion and find >>>> it hard to read your interpretation into the proposal. >>>> >>>> The updated policy after this proposal can be found in RIPE 509 >>>> https://www.ripe.net/publications/docs/ripe-509#----use-of-last----for-pa-allocations >>>> * The following policies come into effect as soon as RIPE NCC is required to >>>> make allocations from the final /8 it receives from the IANA. >>>> >>>> It does not discuss the event where RIPE NCC gets more address space and >>>> could allocate from - which would strictly speaking not be allocation from >>>> the last /8 >>> somewhere along the way, I think, but haven't found it yet, it was >>> said that this >>> policy would get activated when they got the last /8 from IANA, that was the >>> intention. Whatever happend after _that_ point in time, would be covered by >>> that policy. That part was to cover what you mention next... >> >> Are you sure? I mean, when 185/8 has been reiceved from IANA: >> There was some space around left on the free pool and it has been >> allocated under the same "last /8 policy" from that moment or >> followed its own old path? >> I am serius since I wasn't here at that time and I don't really know >> what happened. >> Andrea, can you help me understand what happened to available pool is >> any when 185/8 was reiceved by IANA? >> please understand I signed up 01/2015, when exacly took place the >> first allocation made under "last /8" policy? >> any help would be appreciated >> thanks >> Riccardo >> >>>> Tracing the policy text trough the versions - This text was first removed >>>> between >>>> * RIPE 599 published on 20 December 2013 >>>> https://www.ripe.net/publications/docs/ripe-599#Use-last-for-PA-Allocations >>>> and >>>> * RIPE 604 - published on 4 Feb 2014: >>>> https://www.ripe.net/publications/docs/ripe-604 >>>> >>>> Where the text was changed to: >>>> >>>> The size of the allocation made will be exactly one /22. >>>> The sum of all allocations made to a single LIR by the RIPE NCC after the >>>> 14th of September 2012 is limited to a maximum of 1024 IPv4 addresses (a >>>> single /22 or the equivalent thereof). >>> The side story behind this is probably related to that it was assumed that >>> IANA would get some address space back, address space they again could >>> redistribute to the LIR. When slized up it would at some point not be possible >>> to hand out /22's, only smaller blocks that could add upto a /22. >>> All that would be addresses covered by "the last /8 policy", the runout policy. >>> >>> >>>> and no reference to the last /8. >>>> >>>> So I can easily understand the confusion. >>> The intention was that once the policy was activated it would be there for all >>> future until there was no IPv4 left. It was just called "the last /8 policy" >>> since that's how it started out, the activation point. >>> >>> >>> >>> (I can't find referenced to all of this but it is somewhere in the archives, and >>> guess Geert or you can find it all? Wonder if it might be somewhere in the >>> IETF space or so this was discussed to?) >>> >> >> -- >> Ing. Riccardo Gori >> e-mail:rgori at wirem.net >> Mobile: +39 339 8925947 >> Mobile: +34 602 009 437 >> Profile:https://it.linkedin.com/in/riccardo-gori-74201943 >> WIREM Fiber Revolution >> Net-IT s.r.l. >> Via Cesare Montanari, 2 >> 47521 Cesena (FC) >> Tel +39 0547 1955485 >> Fax +39 0547 1950285 >> >> -------------------------------------------------------------------- >> CONFIDENTIALITY NOTICE >> This message and its attachments are addressed solely to the persons >> above and may contain confidential information. If you have received >> the message in error, be informed that any use of the content hereof >> is prohibited. Please return it immediately to the sender and delete >> the message. Should you have any questions, please contact us by re- >> plying toinfo at wirem.net >> Thank you >> WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) >> -------------------------------------------------------------------- > -- Ing. Riccardo Gori e-mail: rgori at wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info at wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 41774 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logoWirem_4cm_conR.jpg Type: image/jpeg Size: 41774 bytes Desc: not available URL: From rgori at wirem.net Wed Apr 20 13:14:16 2016 From: rgori at wirem.net (Riccardo Gori) Date: Wed, 20 Apr 2016 13:14:16 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <9B0EE8AA-81E3-4060-9DDA-E835C395E631@ucd.ie> References: <57121420.6614c20a.ebfb5.4312@mx.google.com> <5716BC84.2010406@oslo.net> <5717518E.70409@wirem.net> <9B0EE8AA-81E3-4060-9DDA-E835C395E631@ucd.ie> Message-ID: <57176488.6080804@wirem.net> But Niall, I have to admit that these two statement at point 5.3 confuses me a bit: [...] 5.3 Address Recycling Any address space that is returned to the RIPE NCC will be covered by the same rules as the address space intended in section 5.1. This section only applies to address space that is returned to the RIPE NCC and that will not be returned to the IANA but re-issued by the RIPE NCC itself. [...] sorry but maybe this feeds the confusion about last /8 appling only to 185/8 or the whole RIPE available pool thank you for you opinion Riccardo Il 20/04/2016 12:50, Niall O'Reilly ha scritto: > On 20 Apr 2016, at 10:53, Riccardo Gori wrote: > >> Andrea, can you help me understand what happened to available pool is >> any when 185/8 was reiceved by IANA? > > I think this may be the wrong question. > > IIRC, the triggering of the "last /8" policy (as it has usually been > known) > did not coincide with receipt of 185/8 from (NB: not "by") IANA by > RIPE NCC, > but rather with the first allocation by RIPE NCC from 185/8. > > As Roger J?rgensen has explained, once the policy was triggered, it > was to > apply to all subsequent allocations. > > Best regards, > Niall O'Reilly -- Ing. Riccardo Gori e-mail: rgori at wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info at wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logoWirem_4cm_conR.jpg Type: image/jpeg Size: 41774 bytes Desc: not available URL: From gert at space.net Wed Apr 20 13:22:36 2016 From: gert at space.net (Gert Doering) Date: Wed, 20 Apr 2016 13:22:36 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <57176488.6080804@wirem.net> References: <57121420.6614c20a.ebfb5.4312@mx.google.com> <5716BC84.2010406@oslo.net> <5717518E.70409@wirem.net> <9B0EE8AA-81E3-4060-9DDA-E835C395E631@ucd.ie> <57176488.6080804@wirem.net> Message-ID: <20160420112235.GS56633@Space.Net> Hi, On Wed, Apr 20, 2016 at 01:14:16PM +0200, Riccardo Gori wrote: > sorry but maybe this feeds the confusion about last /8 appling only to > 185/8 or the whole RIPE available pool There was confusion about this in the past, so the NCC consulted the working group, we discussed it here on the list, and the conclusion was "as soon as the /8 kicks in, it will affect everything in the RIPE NCC free pool, period" - no going back to the older policy (should the pool grow over a /8), no "different policies for different /8s". I thought we even did a PDP on this, but cannot find it - so maybe someone else with better googling fu can find the discussion. 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: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rgori at wirem.net Wed Apr 20 13:33:04 2016 From: rgori at wirem.net (Riccardo Gori) Date: Wed, 20 Apr 2016 13:33:04 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <20160420112235.GS56633@Space.Net> References: <57121420.6614c20a.ebfb5.4312@mx.google.com> <5716BC84.2010406@oslo.net> <5717518E.70409@wirem.net> <9B0EE8AA-81E3-4060-9DDA-E835C395E631@ucd.ie> <57176488.6080804@wirem.net> <20160420112235.GS56633@Space.Net> Message-ID: <571768F0.8040602@wirem.net> Hi Gert, Il 20/04/2016 13:22, Gert Doering ha scritto: > Hi, > > On Wed, Apr 20, 2016 at 01:14:16PM +0200, Riccardo Gori wrote: >> sorry but maybe this feeds the confusion about last /8 appling only to >> 185/8 or the whole RIPE available pool > There was confusion about this in the past, so the NCC consulted the working > group, we discussed it here on the list, and the conclusion was "as soon > as the /8 kicks in, it will affect everything in the RIPE NCC free pool, > period" - no going back to the older policy (should the pool grow over a > /8), no "different policies for different /8s". > > I thought we even did a PDP on this, but cannot find it - so maybe someone > else with better googling fu can find the discussion. > > Gert Doering > APWG chair thank you for the explanation, as said and known I wan't here at that time Riccardo -- Ing. Riccardo Gori e-mail: rgori at wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info at wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logoWirem_4cm_conR.jpg Type: image/jpeg Size: 41774 bytes Desc: not available URL: From ripe-wgs at radu-adrian.feurdean.net Wed Apr 20 22:43:50 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Wed, 20 Apr 2016 22:43:50 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <9B0EE8AA-81E3-4060-9DDA-E835C395E631@ucd.ie> References: <57121420.6614c20a.ebfb5.4312@mx.google.com> <5716BC84.2010406@oslo.net> <5717518E.70409@wirem.net> <9B0EE8AA-81E3-4060-9DDA-E835C395E631@ucd.ie> Message-ID: <1461185030.1688603.584805897.598E09B8@webmail.messagingengine.com> On Wed, Apr 20, 2016, at 12:50, Niall O'Reilly wrote: > IIRC, the triggering of the "last /8" policy (as it has usually been > known) > did not coincide with receipt of 185/8 from (NB: not "by") IANA by > RIPE NCC, > but rather with the first allocation by RIPE NCC from 185/8. 185/8 received from IANA on feb. 2011 185/8 went "in use" (and the policy started) on sept 2012 > As Roger J?rgensen has explained, once the policy was triggered, it > was to apply to all subsequent allocations. However, in the meantime some events happened: - recovered space issue - space returned to IANA 2012-05 to 2014-04 and gradually returned starting 2014-05 - 2013-03 - no need checking - 2014-04 - no ipv6 requirement - still keeping a high (~= /8) level of "somehow available space" - policy abuse, pushing to limits and general change in "who is a LIR" (get-to-transfer, multi-LIR/company, out-of-continent LIRs - more and more of them, corporate LIRs or simply "just want my damn ASN and /24" LIRs) I hope everybody does realize how this proposal came to life. From ripe-wgs at radu-adrian.feurdean.net Wed Apr 20 23:27:27 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Wed, 20 Apr 2016 23:27:27 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <571646F0.7000508@megagroup.ru> References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <5714E37C.7090908@schiefner.de> <5714FCC0.5040502@idsys.ro> <571646F0.7000508@megagroup.ru> Message-ID: <1461187647.1702048.584880105.5521C6CE@webmail.messagingengine.com> Hi, On Tue, Apr 19, 2016, at 16:55, Stepan Kucherenko wrote: > Why not just check for AAAA record for their main site and mention of > IPv6 somewhere, like "/X for every customer on every tariff" or > something similar depending on the market ? > > It may put enough pressure for them to actually roll it out. Let's not put our marketing departments in the loop. Some of them get scared (for nothing). > I don't support this proposal in it's current state though. It won't > help IPv6 rollout as it is, it can actually make it worse because some > LIRs will be able to postpone it even more. But if combined with > additional incentives...it might just work. Some tiny bit of (free) IPv4 is the incentive. I can't find better. Just need to make sure the condition is well-written. > Although ideas of only giving /24 to those who don't need more, and > probably just /24 after some arbitrary depletion state (/10?) would be > great as well. Anyone writing a policy for that yet ? That was part of the initial idea (see https://ripe70.ripe.net/presentations/93-Last-_8-allocation-size.pdf ) From rogerj at gmail.com Thu Apr 21 08:40:18 2016 From: rogerj at gmail.com (=?UTF-8?Q?Roger_J=C3=B8rgensen?=) Date: Thu, 21 Apr 2016 08:40:18 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <1461185030.1688603.584805897.598E09B8@webmail.messagingengine.com> References: <57121420.6614c20a.ebfb5.4312@mx.google.com> <5716BC84.2010406@oslo.net> <5717518E.70409@wirem.net> <9B0EE8AA-81E3-4060-9DDA-E835C395E631@ucd.ie> <1461185030.1688603.584805897.598E09B8@webmail.messagingengine.com> Message-ID: On Wed, Apr 20, 2016 at 10:43 PM, Radu-Adrian FEURDEAN wrote: > On Wed, Apr 20, 2016, at 12:50, Niall O'Reilly wrote: >> As Roger J?rgensen has explained, once the policy was triggered, it >> was to apply to all subsequent allocations. > > However, in the meantime some events happened: > - recovered space issue - space returned to IANA 2012-05 to 2014-04 and > gradually returned starting 2014-05 already known, space would be returned, and redistributed, it would still be covered by the policy since it would cover all allocation after that point in time. > - 2013-03 - no need checking > - 2014-04 - no ipv6 requirement adjustment, as we do with all policy. Maybe we should make it harder to get IPv4 space? ... but how would that help on the part we really need, more IPv6? Also it might over time make the RIR registry incomplete and full of error, that will hurt the Internet way more than the current gaming actual harm... as sad as that is... :-( > - still keeping a high (~= /8) level of "somehow available space" as said earlier, it does not matter, the policy was there to safeguard some space for future startups. We are just lucky that the space has grown due to return and reallocation! > - policy abuse, pushing to limits and general change in "who is a LIR" > (get-to-transfer, multi-LIR/company, out-of-continent LIRs - more and > more of them, corporate LIRs or simply "just want my damn ASN and /24" > LIRs) ... and here we are again back at the core, the abuse/gaming the system to get more address space. The only real solution to this is to deploy IPv6. Handing out more address space than /22 is not a solution because there will always be a need for more. There is no upper limit and we just run out way faster, and as said over and over again, that will ruin the point with this policy - safeguard some space for the future startups. I am happy with giving RIPE NCC power to turn down request from obvious fake company... however that has it's own problem and not all of them are solvable by this working group, some might not be solvable at all. > I hope everybody does realize how this proposal came to life. giving out more space to those that ask for it is not a good solution with the future in mind. However if everyone want to be greedy here and now and say screw the future (sorry the language)... -- Roger Jorgensen | ROJO9-RIPE rogerj at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From twh at megagroup.ru Thu Apr 21 12:38:39 2016 From: twh at megagroup.ru (Stepan Kucherenko) Date: Thu, 21 Apr 2016 13:38:39 +0300 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <1461187647.1702048.584880105.5521C6CE@webmail.messagingengine.com> References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <5714E37C.7090908@schiefner.de> <5714FCC0.5040502@idsys.ro> <571646F0.7000508@megagroup.ru> <1461187647.1702048.584880105.5521C6CE@webmail.messagingengine.com> Message-ID: <5718ADAF.4000304@megagroup.ru> On 21.04.2016 00:27, Radu-Adrian FEURDEAN wrote: > Hi, > > On Tue, Apr 19, 2016, at 16:55, Stepan Kucherenko wrote: >> Why not just check for AAAA record for their main site and mention of >> IPv6 somewhere, like "/X for every customer on every tariff" or >> something similar depending on the market ? >> >> It may put enough pressure for them to actually roll it out. > > Let's not put our marketing departments in the loop. Some of them get > scared (for nothing). They have to deal with that anyway sooner or later. Also it might become an additional pressure, "our rivals have this strange thing called IPv6 on their site, can we do it too?". >> I don't support this proposal in it's current state though. It won't >> help IPv6 rollout as it is, it can actually make it worse because some >> LIRs will be able to postpone it even more. But if combined with >> additional incentives...it might just work. > > Some tiny bit of (free) IPv4 is the incentive. I can't find better. Just > need to make sure the condition is well-written. There is also a problem with IPv6 roll-outs that it's usually (almost always?) bigger guys, but smaller companies will lag behind for years if not decades. Small incentive for small companies to keep up ? > >> Although ideas of only giving /24 to those who don't need more, and >> probably just /24 after some arbitrary depletion state (/10?) would be >> great as well. Anyone writing a policy for that yet ? > > That was part of the initial idea (see > https://ripe70.ripe.net/presentations/93-Last-_8-allocation-size.pdf ) > Thanks ! Apparently I missed that. Then I think it needs to be considered again, with or without additional allocation. From tjc at ecs.soton.ac.uk Thu Apr 21 13:01:19 2016 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Thu, 21 Apr 2016 12:01:19 +0100 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <5718ADAF.4000304@megagroup.ru> References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <5714E37C.7090908@schiefner.de> <5714FCC0.5040502@idsys.ro> <571646F0.7000508@megagroup.ru> <1461187647.1702048.584880105.5521C6CE@webmail.messagingengine.com> <5718ADAF.4000304@megagroup.ru> Message-ID: > On 21 Apr 2016, at 11:38, Stepan Kucherenko wrote: > > There is also a problem with IPv6 roll-outs that it's usually (almost always?) bigger guys, but smaller companies will lag behind for years if not decades. Small incentive for small companies to keep up ? Not true in the UK at least. Residential IPv6 service has been led by a number of ?smaller? ISPs, for many years. It?s only in the last few months that we?ve seen one of the big ISPs starting to make IPv6 available to their customers; having started the visible roll-out last September, Sky UK are expecting to have well over 90% of their users enabled by July, and all new subscribers are already getting IPv6 by default. Tim From ripe-wgs at radu-adrian.feurdean.net Thu Apr 21 22:19:47 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Thu, 21 Apr 2016 22:19:47 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <5718ADAF.4000304@megagroup.ru> References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <5714E37C.7090908@schiefner.de> <5714FCC0.5040502@idsys.ro> <571646F0.7000508@megagroup.ru> <1461187647.1702048.584880105.5521C6CE@webmail.messagingengine.com> <5718ADAF.4000304@megagroup.ru> Message-ID: <1461269987.3928554.585937049.2AD2759B@webmail.messagingengine.com> On Thu, Apr 21, 2016, at 12:38, Stepan Kucherenko wrote: > > They have to deal with that anyway sooner or later. Also it might become > an additional pressure, "our rivals have this strange thing called IPv6 > on their site, can we do it too?". At which point I prefer being in the situation of telling them "doing this for years already. next." > There is also a problem with IPv6 roll-outs that it's usually (almost > always?) bigger guys, but smaller companies will lag behind for years if > not decades. Small incentive for small companies to keep up ? Small guys are either among the first or among the last to do it. You can find incetives from them (??? extra /22 ???) Big guys are almost never the first (but can start really early) and rarely among the last (even if they can wait a really long time). > >> Although ideas of only giving /24 to those who don't need more, and > >> probably just /24 after some arbitrary depletion state (/10?) would be > >> great as well. Anyone writing a policy for that yet ? > > > > That was part of the initial idea (see > > https://ripe70.ripe.net/presentations/93-Last-_8-allocation-size.pdf ) > > Then I think it needs to be considered again, with or without additional > allocation. At some point yes, that's something that should be done somehow. From frettled at gmail.com Fri Apr 22 07:24:28 2016 From: frettled at gmail.com (Jan Ingvoldstad) Date: Fri, 22 Apr 2016 07:24:28 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <1461269987.3928554.585937049.2AD2759B@webmail.messagingengine.com> References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <5714E37C.7090908@schiefner.de> <5714FCC0.5040502@idsys.ro> <571646F0.7000508@megagroup.ru> <1461187647.1702048.584880105.5521C6CE@webmail.messagingengine.com> <5718ADAF.4000304@megagroup.ru> <1461269987.3928554.585937049.2AD2759B@webmail.messagingengine.com> Message-ID: On Thu, Apr 21, 2016 at 10:19 PM, Radu-Adrian FEURDEAN < ripe-wgs at radu-adrian.feurdean.net> wrote: > > Small guys are either among the first or among the last to do it. You > can find incetives from them (??? extra /22 ???) > This is a part of reasoning I don't understand. "We would like for you to stop drinking Coca-Cola (IPv4) and instead drink water (IPv6). Here, have some more Coca-Cola." How is that an incentive for drinking water? It's not. It's an incentive for _continuing_ drinking Coca-Cola, because hey, maybe the nice fools will give you more Coca-Cola also the next time you run out. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian at idsys.ro Fri Apr 22 08:01:44 2016 From: adrian at idsys.ro (Adrian Pitulac) Date: Fri, 22 Apr 2016 09:01:44 +0300 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <5714E37C.7090908@schiefner.de> <5714FCC0.5040502@idsys.ro> <571646F0.7000508@megagroup.ru> <1461187647.1702048.584880105.5521C6CE@webmail.messagingengine.com> <5718ADAF.4000304@megagroup.ru> <1461269987.3928554.585937049.2AD2759B@webmail.messagingengine.com> Message-ID: <5719BE48.9020209@idsys.ro> Jan, Allow me to translate this to your way of seeing it.. :) Coca-Cola is ending soon, so no one could get any.. There are parties who never drank water, so based on the the policy, they are given a little coca-cola if they start drinking water (IPv6). This if in their help so they can get used to water and start drinking it as coca-cola will end soon. The condition for IPv6 implementation is a must and might be even tougher in this policy as discussed here. Hope I've cleared things for you.. On 22/04/16 08:24, Jan Ingvoldstad wrote: > On Thu, Apr 21, 2016 at 10:19 PM, Radu-Adrian FEURDEAN > > wrote: > > Small guys are either among the first or among the last to do it. You > can find incetives from them (??? extra /22 ???) > > > This is a part of reasoning I don't understand. > > "We would like for you to stop drinking Coca-Cola (IPv4) and instead > drink water (IPv6). Here, have some more Coca-Cola." > > How is that an incentive for drinking water? > > It's not. It's an incentive for _continuing_ drinking Coca-Cola, > because hey, maybe the nice fools will give you more Coca-Cola also > the next time you run out. > > -- > Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Fri Apr 22 10:05:20 2016 From: randy at psg.com (Randy Bush) Date: Fri, 22 Apr 2016 17:05:20 +0900 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <5719BE48.9020209@idsys.ro> References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <5714E37C.7090908@schiefner.de> <5714FCC0.5040502@idsys.ro> <571646F0.7000508@megagroup.ru> <1461187647.1702048.584880105.5521C6CE@webmail.messagingengine.com> <5718ADAF.4000304@megagroup.ru> <1461269987.3928554.585937049.2AD2759B@webmail.messagingengine.com> <5719BE48.9020209@idsys.ro> Message-ID: believing ipv4 allocation as an incentive for ipv6 deployment is yet another in a long line of ipv6 marketing fantasies/failures. sure, give them a v6 prefix, and they may even announce it. but will they convert their infrastructure, oss, back ends, customers, ... to ipv6? that decision is driven by very different business cases. the purpose of the last /8 policy was to let new entrants have teenie bits of ipv4 to join the internet, which will require v4 for a long while. randy From twh at megagroup.ru Fri Apr 22 10:46:38 2016 From: twh at megagroup.ru (Stepan Kucherenko) Date: Fri, 22 Apr 2016 11:46:38 +0300 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <5714E37C.7090908@schiefner.de> <5714FCC0.5040502@idsys.ro> <571646F0.7000508@megagroup.ru> <1461187647.1702048.584880105.5521C6CE@webmail.messagingengine.com> <5718ADAF.4000304@megagroup.ru> <1461269987.3928554.585937049.2AD2759B@webmail.messagingengine.com> <5719BE48.9020209@idsys.ro> Message-ID: <5719E4EE.6070609@megagroup.ru> On 22.04.2016 11:05, Randy Bush wrote: > believing ipv4 allocation as an incentive for ipv6 deployment is yet > another in a long line of ipv6 marketing fantasies/failures. sure, give > them a v6 prefix, and they may even announce it. but will they convert > their infrastructure, oss, back ends, customers, ... to ipv6? that > decision is driven by very different business cases. > > the purpose of the last /8 policy was to let new entrants have teenie > bits of ipv4 to join the internet, which will require v4 for a long > while. > > randy > Last /8 policy came with some strings attached (IPv6 allocation) but there is no way a new LIR will show some IPv6 progress before initial IPv4 allocation was made. But with additional allocation it IS possible to check if they even done anything in that time. I have no illusions, giving additional allocations is basically a small financial incentive that will only be worth it for small players. It has little value as of original proposal, which I oppose (no strings attached, just get your space and prolong your IPv4 existence). But it might be used to push some of smaller LIRs to IPv6 if we add additional requirements. 5-stars RIPEness with even higher thresholds + AAAA on main site + IPv6 as part of usual services to customers ? It will be hard to achieve without actual rollout, and additional allocations to LIRs will be either small in number or useful. From ripe at liopen.fr Fri Apr 22 11:08:09 2016 From: ripe at liopen.fr (Denis Fondras) Date: Fri, 22 Apr 2016 11:08:09 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <5719E4EE.6070609@megagroup.ru> References: <5714FCC0.5040502@idsys.ro> <571646F0.7000508@megagroup.ru> <1461187647.1702048.584880105.5521C6CE@webmail.messagingengine.com> <5718ADAF.4000304@megagroup.ru> <1461269987.3928554.585937049.2AD2759B@webmail.messagingengine.com> <5719BE48.9020209@idsys.ro> <5719E4EE.6070609@megagroup.ru> Message-ID: <20160422090809.GI4341@enforcer.ledeuns.net> > Last /8 policy came with some strings attached (IPv6 allocation) but there > is no way a new LIR will show some IPv6 progress before initial IPv4 > allocation was made. > Can you elaborate a bit please ? Denis From twh at megagroup.ru Fri Apr 22 11:19:32 2016 From: twh at megagroup.ru (Stepan Kucherenko) Date: Fri, 22 Apr 2016 12:19:32 +0300 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <20160422090809.GI4341@enforcer.ledeuns.net> References: <5714FCC0.5040502@idsys.ro> <571646F0.7000508@megagroup.ru> <1461187647.1702048.584880105.5521C6CE@webmail.messagingengine.com> <5718ADAF.4000304@megagroup.ru> <1461269987.3928554.585937049.2AD2759B@webmail.messagingengine.com> <5719BE48.9020209@idsys.ro> <5719E4EE.6070609@megagroup.ru> <20160422090809.GI4341@enforcer.ledeuns.net> Message-ID: <5719ECA4.9090002@megagroup.ru> I mean if there is a new LIR who gets his initial /22 allocation and /32 IPv6 allocation, it doesn't mean he will do anything with that /32 IPv6. And it's not possible to check if he will do that. But if in a couple of years he comes for additional /22, RIPE can check if he actually rolled out and accept or deny his request based on that. That way LIRs can plan and execute IPv6 rollout if they want more legacy space, or don't and live with what was given to them at the start. On 22.04.2016 12:08, Denis Fondras wrote: >> Last /8 policy came with some strings attached (IPv6 allocation) but there >> is no way a new LIR will show some IPv6 progress before initial IPv4 >> allocation was made. >> > > Can you elaborate a bit please ? > > Denis > From ripe-wgs at radu-adrian.feurdean.net Fri Apr 22 14:29:02 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Fri, 22 Apr 2016 14:29:02 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <5714E37C.7090908@schiefner.de> <5714FCC0.5040502@idsys.ro> <571646F0.7000508@megagroup.ru> <1461187647.1702048.584880105.5521C6CE@webmail.messagingengine.com> <5718ADAF.4000304@megagroup.ru> <1461269987.3928554.585937049.2AD2759B@webmail.messagingengine.com> Message-ID: <1461328142.323197.586543369.787643CA@webmail.messagingengine.com> On Fri, Apr 22, 2016, at 07:24, Jan Ingvoldstad wrote: > On Thu, Apr 21, 2016 at 10:19 PM, Radu-Adrian FEURDEAN < > ripe-wgs at radu-adrian.feurdean.net> wrote: > > > > Small guys are either among the first or among the last to do it. You > > can find incetives from them (??? extra /22 ???) > > > > This is a part of reasoning I don't understand. > > "We would like for you to stop drinking Coca-Cola (IPv4) and instead > drink water (IPv6). Here, have some more Coca-Cola." > > How is that an incentive for drinking water? You are talking about people addicted to Coca-Cola. You can't just ask them to plain stop drinking Coca-Cola, as long as you have some (and even if you no longer have, it's still difficult). You can just say "If you start drinking water, there may be some small amounts until you fully switch to water". At least that's the idea. And it's suposed to only be applied to small guys, since the big ones still have large stocks to support the transition. From ripe-wgs at radu-adrian.feurdean.net Fri Apr 22 14:37:33 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Fri, 22 Apr 2016 14:37:33 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <5719E4EE.6070609@megagroup.ru> References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <5714E37C.7090908@schiefner.de> <5714FCC0.5040502@idsys.ro> <571646F0.7000508@megagroup.ru> <1461187647.1702048.584880105.5521C6CE@webmail.messagingengine.com> <5718ADAF.4000304@megagroup.ru> <1461269987.3928554.585937049.2AD2759B@webmail.messagingengine.com> <5719BE48.9020209@idsys.ro> <5719E4EE.6070609@megagroup.ru> Message-ID: <1461328653.325099.586549369.3964CBDB@webmail.messagingengine.com> On Fri, Apr 22, 2016, at 10:46, Stepan Kucherenko wrote: > Last /8 policy came with some strings attached (IPv6 allocation) but > there is no way a new LIR will show some IPv6 progress before initial > IPv4 allocation was made. But with additional allocation it IS possible > to check if they even done anything in that time. Right now, there's no string attached. As long as the issue of "new player, get IPv6 ASAP" one of the 2 ways to achieve this is to stop handing out allocations directly, but "lease" them for X months/years, and recover it if no IPv6 has been deployed in the meanwhile. The complexity of such a thing is much higher, but if anybody would find the good wording for this, I would support. The second one would be "no more IPv4 at all". We're not there yet. > 5-stars RIPEness with even higher thresholds + AAAA on main site + IPv6 > as part of usual services to customers ? It will be hard to achieve > without actual rollout, and additional allocations to LIRs will be > either small in number or useful. I agree, with the reserve of clearly defining "main site". From nick at foobar.org Fri Apr 22 15:05:59 2016 From: nick at foobar.org (Nick Hilliard) Date: Fri, 22 Apr 2016 14:05:59 +0100 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <1461328142.323197.586543369.787643CA@webmail.messagingengine.com> References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <5714E37C.7090908@schiefner.de> <5714FCC0.5040502@idsys.ro> <571646F0.7000508@megagroup.ru> <1461187647.1702048.584880105.5521C6CE@webmail.messagingengine.com> <5718ADAF.4000304@megagroup.ru> <1461269987.3928554.585937049.2AD2759B@webmail.messagingengine.com> <1461328142.323197.586543369.787643CA@webmail.messagingengine.com> Message-ID: <571A21B7.5080305@foobar.org> Radu-Adrian FEURDEAN wrote: > You are talking about people addicted to Coca-Cola. You can't just ask > them to plain stop drinking Coca-Cola, as long as you have some (and > even if you no longer have, it's still difficult). People can be as addicted to using ipv4 addresses as they want. It changes nothing: the supply of previously unused address blocks is running out, and the only issue with allocation of the remainder is how to allocate them rather than the uncomfortable reality that they will soon disappear completely and we will have no options for internet connectivity other than ipv6 and the ipv4 address market. Regarding the current allocation policies, you still have not addressed the query that several people have raised about why it is better to shut off opportunities for future internet service market entrants than it is to make things marginally easier for a small segment of the existing market for a short period of time, other than "but it hurts". Nick From ripe-wgs at radu-adrian.feurdean.net Fri Apr 22 17:01:45 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Fri, 22 Apr 2016 17:01:45 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <571A21B7.5080305@foobar.org> References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <5714E37C.7090908@schiefner.de> <5714FCC0.5040502@idsys.ro> <571646F0.7000508@megagroup.ru> <1461187647.1702048.584880105.5521C6CE@webmail.messagingengine.com> <5718ADAF.4000304@megagroup.ru> <1461269987.3928554.585937049.2AD2759B@webmail.messagingengine.com> <1461328142.323197.586543369.787643CA@webmail.messagingengine.com> <571A21B7.5080305@foobar.org> Message-ID: <1461337305.363622.586687217.441351EC@webmail.messagingengine.com> On Fri, Apr 22, 2016, at 15:05, Nick Hilliard wrote: > Regarding the current allocation policies, you still have not addressed > the query that several people have raised about why it is better to shut > off opportunities for future internet service market entrants than it is > to make things marginally easier for a small segment of the existing > market for a short period of time, other than "but it hurts". Hi, I do understand that. I just do not agree with the "as long as possible, no matter what" approach. For me, the issue is that right now we are in a "please suffer, the solution is not working yet" situation. Pain management. The only solution right now is pain suppressors. Some have stocks, some just get enough to see it's possible but not enough to get to a point where they can get on by themselves. Only a few are not affected at all. From rhe at nosc.ja.net Fri Apr 22 17:06:28 2016 From: rhe at nosc.ja.net (Rob Evans) Date: Fri, 22 Apr 2016 16:06:28 +0100 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <1461337305.363622.586687217.441351EC@webmail.messagingengine.com> References: <5714FCC0.5040502@idsys.ro> <571646F0.7000508@megagroup.ru> <1461187647.1702048.584880105.5521C6CE@webmail.messagingengine.com> <5718ADAF.4000304@megagroup.ru> <1461269987.3928554.585937049.2AD2759B@webmail.messagingengine.com> <1461328142.323197.586543369.787643CA@webmail.messagingengine.com> <571A21B7.5080305@foobar.org> <1461337305.363622.586687217.441351EC@webmail.messagingengine.com> Message-ID: <20160422150628.GA22536@jobspension.ja.net> Hi, > I do understand that. I just do not agree with the "as long as possible, > no matter what" approach. > For me, the issue is that right now we are in a "please suffer, the > solution is not working yet" situation. > Pain management. The only solution right now is pain suppressors. Some > have stocks, some just get enough to see it's possible but not enough to > get to a point where they can get on by themselves. Only a few are not > affected at all. Whilst this thread had already seen enough metaphors today, unless you know how long the pain is going to last, how do you know if we have enough painkillers? Cheers, Rob From adrian at idsys.ro Fri Apr 22 17:13:46 2016 From: adrian at idsys.ro (Adrian Pitulac) Date: Fri, 22 Apr 2016 18:13:46 +0300 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <571A21B7.5080305@foobar.org> References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <5714E37C.7090908@schiefner.de> <5714FCC0.5040502@idsys.ro> <571646F0.7000508@megagroup.ru> <1461187647.1702048.584880105.5521C6CE@webmail.messagingengine.com> <5718ADAF.4000304@megagroup.ru> <1461269987.3928554.585937049.2AD2759B@webmail.messagingengine.com> <1461328142.323197.586543369.787643CA@webmail.messagingengine.com> <571A21B7.5080305@foobar.org> Message-ID: <571A3FAA.1050603@idsys.ro> On 22/04/16 16:05, Nick Hilliard wrote: > Regarding the current allocation policies, you still have not addressed > the query that several people have raised about why it is better to shut > off opportunities for future internet service market entrants than it is > to make things marginally easier for a small segment of the existing > market for a short period of time, other than "but it hurts". > > Nick I think this has not been expressed directly, but IPv6 implementation obligations in this policy might be the reason why it could be MUCH better than existing policy who offers the opportunities for future entrants but does not have a long term solution for the real problem (IPv4 exhaustion). From nick at foobar.org Fri Apr 22 17:37:42 2016 From: nick at foobar.org (Nick Hilliard) Date: Fri, 22 Apr 2016 16:37:42 +0100 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <571A3FAA.1050603@idsys.ro> References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <5714E37C.7090908@schiefner.de> <5714FCC0.5040502@idsys.ro> <571646F0.7000508@megagroup.ru> <1461187647.1702048.584880105.5521C6CE@webmail.messagingengine.com> <5718ADAF.4000304@megagroup.ru> <1461269987.3928554.585937049.2AD2759B@webmail.messagingengine.com> <1461328142.323197.586543369.787643CA@webmail.messagingengine.com> <571A21B7.5080305@foobar.org> <571A3FAA.1050603@idsys.ro> Message-ID: <571A4546.1020109@foobar.org> Adrian Pitulac wrote: > I think this has not been expressed directly, but IPv6 implementation > obligations in this policy might be the reason why it could be MUCH > better than existing policy who offers the opportunities for future > entrants but does not have a long term solution for the real problem > (IPv4 exhaustion). If you think ipv6 implementation obligations are a good idea, then please feel free to put forward a separate policy to introduce them, but don't confuse them with changing the last /8 allocation policies because they are fundamentally different things. Incidentally, the reason Randy Bush wrote this earlier this morning: > believing ipv4 allocation as an incentive for ipv6 deployment is yet > another in a long line of ipv6 marketing fantasies/failures. sure, give > them a v6 prefix, and they may even announce it. but will they convert > their infrastructure, oss, back ends, customers, ... to ipv6? that > decision is driven by very different business cases. ... was because he - and many other people - watched for several years as top-down policy obligations to implement OSI protocols as communication standards failed utterly and beyond hope. They failed because top-down decrees don't work. As a separate issue, the RIPE NCC is not in the business of telling its members how to run their networks. Nick From rgori at wirem.net Fri Apr 22 17:44:33 2016 From: rgori at wirem.net (Riccardo Gori) Date: Fri, 22 Apr 2016 17:44:33 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <57121420.6614c20a.ebfb5.4312@mx.google.com> <5716BC84.2010406@oslo.net> <5717518E.70409@wirem.net> <9B0EE8AA-81E3-4060-9DDA-E835C395E631@ucd.ie> <1461185030.1688603.584805897.598E09B8@webmail.messagingengine.com> Message-ID: Hi Roger, Il 21/04/2016 08:40, Roger J?rgensen ha scritto: > On Wed, Apr 20, 2016 at 10:43 PM, Radu-Adrian FEURDEAN > wrote: >> On Wed, Apr 20, 2016, at 12:50, Niall O'Reilly wrote: > >>> As Roger J?rgensen has explained, once the policy was triggered, it >>> was to apply to all subsequent allocations. >> However, in the meantime some events happened: >> - recovered space issue - space returned to IANA 2012-05 to 2014-04 and >> gradually returned starting 2014-05 > already known, space would be returned, and redistributed, it would still > be covered by the policy since it would cover all allocation after that point > in time. > > >> - 2013-03 - no need checking >> - 2014-04 - no ipv6 requirement > adjustment, as we do with all policy. Maybe we should make it harder > to get IPv4 space? ... but how would that help on the part we really need, > more IPv6? Also it might over time make the RIR registry incomplete > and full of error, that will hurt the Internet way more than the current > gaming actual harm... as sad as that is... :-( > > >> - still keeping a high (~= /8) level of "somehow available space" > as said earlier, it does not matter, the policy was there to safeguard > some space for future startups. We are just lucky that the space has > grown due to return and reallocation! Are you sure that we all here are saving space for new entrants? or there can be someone saving economic value of its allocations? Everyone of us should be aware that when a resource is exhausted there's no more value in it. I would know all allocations holded by pleople to figure how much everyone is philanthropic Please understand I am not referring to anyone in particoular can be all of us me included or nobody And again remeber I am not for fast depletion. > > >> - policy abuse, pushing to limits and general change in "who is a LIR" >> (get-to-transfer, multi-LIR/company, out-of-continent LIRs - more and >> more of them, corporate LIRs or simply "just want my damn ASN and /24" >> LIRs) > ... and here we are again back at the core, the abuse/gaming the system > to get more address space. The only real solution to this is to deploy > IPv6. Handing out more address space than /22 is not a solution > because there will always be a need for more. There is no upper limit > and we just run out way faster, and as said over and over again, that > will ruin the point with this policy - safeguard some space for the future > startups. > > > > I am happy with giving RIPE NCC power to turn down request from > obvious fake company... however that has it's own problem and not > all of them are solvable by this working group, some might not be > solvable at all. > > >> I hope everybody does realize how this proposal came to life. > giving out more space to those that ask for it is not a good solution > with the future in mind. However if everyone want to be greedy here > and now and say screw the future (sorry the language)... > > > -- Ing. Riccardo Gori e-mail: rgori at wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info at wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logoWirem_4cm_conR.jpg Type: image/jpeg Size: 41774 bytes Desc: not available URL: From nick at foobar.org Fri Apr 22 18:00:16 2016 From: nick at foobar.org (Nick Hilliard) Date: Fri, 22 Apr 2016 17:00:16 +0100 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <1461337305.363622.586687217.441351EC@webmail.messagingengine.com> References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <5714E37C.7090908@schiefner.de> <5714FCC0.5040502@idsys.ro> <571646F0.7000508@megagroup.ru> <1461187647.1702048.584880105.5521C6CE@webmail.messagingengine.com> <5718ADAF.4000304@megagroup.ru> <1461269987.3928554.585937049.2AD2759B@webmail.messagingengine.com> <1461328142.323197.586543369.787643CA@webmail.messagingengine.com> <571A21B7.5080305@foobar.org> <1461337305.363622.586687217.441351EC@webmail.messagingengine.! com> Message-ID: <571A4A90.6090109@foobar.org> Radu-Adrian FEURDEAN wrote: > I do understand that. I just do not agree with the "as long as possible, > no matter what" approach. > For me, the issue is that right now we are in a "please suffer, the > solution is not working yet" situation. and your solution is that you want future market entrants to suffer more than you're suffering now because there will be no address space whatsoever left for them? Nick From h.lu at anytimechinese.com Fri Apr 22 18:11:29 2016 From: h.lu at anytimechinese.com (h.lu at anytimechinese.com) Date: Sat, 23 Apr 2016 00:11:29 +0800 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <571A4A90.6090109@foobar.org> References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <5714E37C.7090908@schiefner.de> <5714FCC0.5040502@idsys.ro> <571646F0.7000508@megagroup.ru> <1461187647.1702048.584880105.5521C6CE@webmail.messagingengine.com> <5718ADAF.4000304@megagroup.ru> <1461269987.3928554.585937049.2AD2759B@webmail.messagingengine.com> <1461328142.323197.586543369.787643CA@webmail.messagingengine.com> <571A21B7.5080305@foobar.org> <1461337305.363622.586687217.441351EC@webmail.messagingengine.! com> <571A4A90.6090109@foobar.org> Message-ID: Hi Fairly speaking, if market price above certain point, people will deplete the pool really fast, as long as it makes business sense. Unless we start using /24 policy in which effectively encourage people seek growth in the transfer market---in which it is what it should be, is not such a bad idea. > On 23 Apr 2016, at 00:00, Nick Hilliard wrote: > > Radu-Adrian FEURDEAN wrote: >> I do understand that. I just do not agree with the "as long as possible, >> no matter what" approach. >> For me, the issue is that right now we are in a "please suffer, the >> solution is not working yet" situation. > > and your solution is that you want future market entrants to suffer more > than you're suffering now because there will be no address space > whatsoever left for them? > > Nick > From rgori at wirem.net Fri Apr 22 18:10:13 2016 From: rgori at wirem.net (Riccardo Gori) Date: Fri, 22 Apr 2016 18:10:13 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <5714E37C.7090908@schiefner.de> <5714FCC0.5040502@idsys.ro> <571646F0.7000508@megagroup.ru> <1461187647.1702048.584880105.5521C6CE@webmail.messagingengine.com> <5718ADAF.4000304@megagroup.ru> <1461269987.3928554.585937049.2AD2759B@webmail.messagingengine.com> <5719BE48.9020209@idsys.ro> Message-ID: <0bbb1380-774d-9abd-b844-3844d34bee6c@wirem.net> Hi Randy, Il 22/04/2016 10:05, Randy Bush ha scritto: > believing ipv4 allocation as an incentive for ipv6 deployment is yet > another in a long line of ipv6 marketing fantasies/failures. sure, give > them a v6 prefix, and they may even announce it. but will they convert > their infrastructure, oss, back ends, customers, ... to ipv6? that > decision is driven by very different business cases. I can assure that I am doing any effort to do it. The way I can, but doing it. I also have customers asking the same time: IPv4 resources and cusultin service about IPv6 Most common case is "can you give me this some resources for my project? In the while we want to start IPv6 can you help us in doing it?" normally is /27 to /25. reiceved one request for one /23 > > the purpose of the last /8 policy was to let new entrants have teenie > bits of ipv4 to join the internet, which will require v4 for a long > while. I cannot be against this. But if it was so easy someone should explain why existing LIRs already holding address space can submit a request for one /22 from pool after 09/2012 Not discriminate between LIRs sizes is a point but for competitiveness we can't say a /22 is enought to survive on the market today. > > randy > -- Ing. Riccardo Gori e-mail: rgori at wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info at wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logoWirem_4cm_conR.jpg Type: image/jpeg Size: 41774 bytes Desc: not available URL: From ripe-wgs at radu-adrian.feurdean.net Fri Apr 22 18:30:30 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Fri, 22 Apr 2016 18:30:30 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <571A4546.1020109@foobar.org> References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <5714E37C.7090908@schiefner.de> <5714FCC0.5040502@idsys.ro> <571646F0.7000508@megagroup.ru> <1461187647.1702048.584880105.5521C6CE@webmail.messagingengine.com> <5718ADAF.4000304@megagroup.ru> <1461269987.3928554.585937049.2AD2759B@webmail.messagingengine.com> <1461328142.323197.586543369.787643CA@webmail.messagingengine.com> <571A21B7.5080305@foobar.org> <571A3FAA.1050603@idsys.ro> <571A4546.1020109@foobar.org> Message-ID: <1461342630.385283.586775225.50C25246@webmail.messagingengine.com> On Fri, Apr 22, 2016, at 17:37, Nick Hilliard wrote: > As a separate issue, the RIPE NCC is not in the business of telling its > members how to run their networks. Still a somehow separate issue, it shouldn't be in the "sell IPs" business neither, but it looks like it's exactly what it's doing with the multiple-LIR stuff. Follow-up 27/05. From ripe-wgs at radu-adrian.feurdean.net Fri Apr 22 18:39:59 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Fri, 22 Apr 2016 18:39:59 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <571A4A90.6090109@foobar.org> References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <5714E37C.7090908@schiefner.de> <5714FCC0.5040502@idsys.ro> <571646F0.7000508@megagroup.ru> <1461187647.1702048.584880105.5521C6CE@webmail.messagingengine.com> <5718ADAF.4000304@megagroup.ru> <1461269987.3928554.585937049.2AD2759B@webmail.messagingengine.com> <1461328142.323197.586543369.787643CA@webmail.messagingengine.com> <571A21B7.5080305@foobar.org> <571A4A90.6090109@foobar.org> Message-ID: <1461343199.386888.586785929.02876E0D@webmail.messagingengine.com> On Fri, Apr 22, 2016, at 18:00, Nick Hilliard wrote: > Radu-Adrian FEURDEAN wrote: > > I do understand that. I just do not agree with the "as long as possible, > > no matter what" approach. > > For me, the issue is that right now we are in a "please suffer, the > > solution is not working yet" situation. > > and your solution is that you want future market entrants to suffer more > than you're suffering now because there will be no address space > whatsoever left for them? They will eventually do it anyway. And I really don't belive that with the new proposal it will be in 18 months whereas with the current one it will be in more than 5 years. Those being said, historically, many new (small) entrants were not becoming LIRs from day 1. They were usually starting with some space from an existing LIR, some of them going multihomed with that space, and only then becoming LIR and having "their own space". The transfer market is discouraging this, and the limited space is also pushing many of them to become LIR not because they really want to, but because some upstream providers encourage them to do so in order to save their own space ("wanna /24 - become LIR"). -- Radu-Adrian FEURDEAN fr.ccs From frettled at gmail.com Fri Apr 22 22:19:31 2016 From: frettled at gmail.com (Jan Ingvoldstad) Date: Fri, 22 Apr 2016 22:19:31 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <1461328142.323197.586543369.787643CA@webmail.messagingengine.com> References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <5714E37C.7090908@schiefner.de> <5714FCC0.5040502@idsys.ro> <571646F0.7000508@megagroup.ru> <1461187647.1702048.584880105.5521C6CE@webmail.messagingengine.com> <5718ADAF.4000304@megagroup.ru> <1461269987.3928554.585937049.2AD2759B@webmail.messagingengine.com> <1461328142.323197.586543369.787643CA@webmail.messagingengine.com> Message-ID: On Fri, Apr 22, 2016 at 2:29 PM, Radu-Adrian FEURDEAN < ripe-wgs at radu-adrian.feurdean.net> wrote: > > You are talking about people addicted to Coca-Cola. You can't just ask > them to plain stop drinking Coca-Cola, as long as you have some (and > even if you no longer have, it's still difficult). You can just say "If > you start drinking water, there may be some small amounts until you > fully switch to water". At least that's the idea. And it's suposed to > only be applied to small guys, since the big ones still have large > stocks to support the transition. > I'm sorry, this reasoning simply doesn't make sense to me, in spite of the slightly condescending answer from Adrian, and your continued use of the analogy. There is little evidence to support that line of reasoning, and all too much against it. Additionally, little thought seems to have been spent considering how this should be implemented, I mostly see some hand-waving here. My feeling is that this policy will serve two groups in particular: - Speculants - Spammers who want "clean" IPv4 space for their ventures, because IPv6 spamming isn't useful yet While this clearly isn't the intent you have stated in your policy, I believe this is what it will be used for, regrettably. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Sat Apr 23 04:53:20 2016 From: randy at psg.com (Randy Bush) Date: Sat, 23 Apr 2016 11:53:20 +0900 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: <1461337305.363622.586687217.441351EC@webmail.messagingengine.com> References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <5714E37C.7090908@schiefner.de> <5714FCC0.5040502@idsys.ro> <571646F0.7000508@megagroup.ru> <1461187647.1702048.584880105.5521C6CE@webmail.messagingengine.com> <5718ADAF.4000304@megagroup.ru> <1461269987.3928554.585937049.2AD2759B@webmail.messagingengine.com> <1461328142.323197.586543369.787643CA@webmail.messagingengine.com> <571A21B7.5080305@foobar.org> <1461337305.363622.586687217.441351EC@webmail.messagingengine.com> Message-ID: > For me, the issue is that right now we are in a "please suffer, the > solution is not working yet" situation. what solution is not working for you? randy, running v6 commercially since '97 From ripe-wgs at radu-adrian.feurdean.net Sat Apr 23 22:07:49 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Sat, 23 Apr 2016 22:07:49 +0200 Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) In-Reply-To: References: <570F9005.4090008@ripe.net> <9B3BFE0A18160E40BAF1950414D10FAE5B22AEF8@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF14@WPMBX010.bskyb.com> <9B3BFE0A18160E40BAF1950414D10FAE5B22AF84@WPMBX010.bskyb.com> <20160415084156.GO56633@Space.Net> <5710AE13.8060201@idsys.ro> <5714E37C.7090908@schiefner.de> <5714FCC0.5040502@idsys.ro> <571646F0.7000508@megagroup.ru> <1461187647.1702048.584880105.5521C6CE@webmail.messagingengine.com> <5718ADAF.4000304@megagroup.ru> <1461269987.3928554.585937049.2AD2759B@webmail.messagingengine.com> <1461328142.323197.586543369.787643CA@webmail.messagingengine.com> <571A21B7.5080305@foobar.org> <1461337305.363622.586687217.441351EC@webmail.messagingengine.com> Message-ID: <1461442069.3468747.587594257.0C8792F8@webmail.messagingengine.com> On Sat, Apr 23, 2016, at 04:53, Randy Bush wrote: > > For me, the issue is that right now we are in a "please suffer, the > > solution is not working yet" situation. > > what solution is not working for you? Commercially, IPv6 does not work. IPv4 does, it's even required. Companies (non-IT ones) don't care about IPv6 yet. They just want their fixed IPv4 or IPv4 block (/29 and up) for their internet connections - can't provide it, somebody else (usually big/old player) can. > randy, running v6 commercially since '97 Like selling IPv6-based services with no or degraded IPv4 ? From mschmidt at ripe.net Mon Apr 25 13:54:57 2016 From: mschmidt at ripe.net (Marco Schmidt) Date: Mon, 25 Apr 2016 13:54:57 +0200 Subject: [address-policy-wg] RIPE 71 Address Policy WG Draft Minutes Message-ID: <571E0591.3050804@ripe.net> Dear colleagues, The draft minutes from the Address Policy Working Group sessions at RIPE 71 have now been published: https://www.ripe.net/participate/ripe/wg/ap/minutes/ripe-71 Please let us know of any corrections or amendments. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC From barfieldsamueliii at gmail.com Tue Apr 26 18:46:06 2016 From: barfieldsamueliii at gmail.com (Samuel Barfield III) Date: Tue, 26 Apr 2016 11:46:06 -0500 Subject: [address-policy-wg] samuel.iii.barfield@hotmail.com Message-ID: Samuel Samuel Business of Information From sergiu.ianciuc at itns.md Fri Apr 29 10:38:00 2016 From: sergiu.ianciuc at itns.md (Sergiu IANCIUC) Date: Fri, 29 Apr 2016 11:38:00 +0300 Subject: [address-policy-wg] Fwd: [ncc-announce] [news] RIPE Policy Proposals - April Update In-Reply-To: <572318CF.6020601@ripe.net> References: <572318CF.6020601@ripe.net> Message-ID: <194432980.20160429113800@itns.md> hello, PLS, take in consideration the situation Company X has a /22 from its LIR. The LIR can not offer more IPv4 spaces and the Company X becomes a LIR to satisfy its needs. Now, it is logical that the LIR (if agreed between these 2 LIRs) transfers the space allocated to the Company X (now the new LIR) AND THIS have to not be the part from the policy - "requirements, such as the LIR has not transferred any IPv4 address space before." What are you thinking about? Best Regards, - Sergiu IANCIUC SC ITNS.NET SRL MD-2068, Moldova or. Chisinau, str. Miron Costin 3/1 tel.: +373 22 877 877 fax : +373 22 44 11 73 mobile: +373 690 22 111 url: http://www.itns.md Save a tree... Don't print this email unless you have to... This is a forwarded message From: Marco Schmidt To: ncc-announce at ripe.net Date: Friday, April 29, 2016, 11:18:23 AM Subject: [ncc-announce] [news] RIPE Policy Proposals - April Update ===8<==============Original message text=============== Dear colleagues, Here is our monthly overview of open policy proposals and their stage in the RIPE Policy Development Process (PDP). If you wish to join the discussion about a particular proposal, please do so on the relevant working group mailing list. Proposals Open for Discussion: 2015-05, "Revision of Last /8 Allocation Criteria" Proposals Awaiting Input: 2015-04, "RIPE Resource Transfer Policies" 2016-01, "Include Legacy Internet Resource Holders in the Abuse-c Policy" Proposal Overviews: PROPOSAL: 2015-05, "Revision of Last /8 Allocation Criteria" OVERVIEW: Aims to allow LIRs to request an additional /22 IPv4 allocation from the RIPE NCC every 18 months. The latest version of the proposal suggests several requirements, such as the LIR cannot hold more than a /20 IPv4, must document their IPv6 deployment and has not transferred any IPv4 address space before. STATUS: Discussion Phase WHERE TO COMMENT: Address Policy Working Group: address-policy-wg at ripe.net DEADLINE: 13 May 2016 FULL PROPOSAL: https://www.ripe.net/participate/policies/proposals/2015-05 ===== The following proposals are awaiting input before they can go any further in the PDP. PROPOSAL: 2015-04, "RIPE Resource Transfer Policies" OVERVIEW: Aims to create a single transfer policy with all relevant information on the transfer of Internet number resources, replacing text in several RIPE Policies. The proposal also introduces a 24-month holding period for IPv4 addresses and 16-bit ASNs after any change of holdership. RIPE NCC IMPACT ANALYSIS: Includes the point how the 24-month holding period for scarce resources will be applied. STATUS: Review Phase ? Awaiting decision from working group chair FULL PROPOSAL: https://www.ripe.net/participate/policies/proposals/2015-04 PROPOSAL: 2016-01, "Include Legacy Internet Resource Holders in the Abuse-c Policy" OVERVIEW: Aims for a mandatory abuse contact for Legacy Internet Resource holders in the RIPE Database. STATUS: Discussion Phase ? Awaiting decision from proposer FULL PROPOSAL: https://www.ripe.net/participate/policies/proposals/2016-01 The RIPE NCC provides an overview of current RIPE Policy Proposals on www.ripe.net: https://www.ripe.net/participate/policies/current-proposals/current-policy-proposals We look forward to your involvement in the PDP. Kind regards, Marco Schmidt RIPE Policy Development Officer RIPE NCC ===8<===========End of original message text=========== From rgori at wirem.net Sat Apr 30 07:33:49 2016 From: rgori at wirem.net (Riccardo Gori) Date: Sat, 30 Apr 2016 07:33:49 +0200 Subject: [address-policy-wg] Fwd: [ncc-announce] [news] RIPE Policy Proposals - April Update In-Reply-To: <194432980.20160429113800@itns.md> References: <572318CF.6020601@ripe.net> <194432980.20160429113800@itns.md> Message-ID: <7d770256-c3ee-f43d-009f-c1fe8337167e@wirem.net> Dear Sergiu, about your example and its eventual realtionship with the proposal 2015-05: Company X would have not limit in receive address space as described in transfert or allocation policies. The limit described in 2015-05 would be applied to the LIR that assigned space to Company X and, as described in your example, later transfered the space in Company X registry. This LIR is supposed to not need address space as it moved it outside its registry so it would not be able to request an additional /22 allocation from pool outside 185/8 standing on 2015-05 proposal On the other hand if Company X after its sing up as a new LIR after 18 months need more space and there is enough space outside 185/8 would be able to request an additional /22 standing on 2015-05 proposal. The LIR that offered the first /22 to Company X as "assigned resource" could also request an additional /22 allocation if its registry is holding less than a /20 IPv4. hope this help regards Riccardo Il 29/04/2016 10:38, Sergiu IANCIUC ha scritto: > hello, > > PLS, take in consideration the situation > > Company X has a /22 from its LIR. The LIR can not offer more IPv4 > spaces and the Company X becomes a LIR to satisfy its needs. Now, it > is logical that the LIR (if agreed between these 2 LIRs) transfers the > space allocated to the Company X (now the new LIR) AND THIS have to > not be the part from the policy - > > "requirements, such as the LIR has not transferred any IPv4 address > space before." > > What are you thinking about? > > > Best Regards, > > > - > Sergiu IANCIUC > SC ITNS.NET SRL > > > MD-2068, Moldova > or. Chisinau, str. Miron Costin 3/1 > tel.: +373 22 877 877 > fax : +373 22 44 11 73 > mobile: +373 690 22 111 > url: http://www.itns.md > > > Save a tree... Don't print this email unless you have to... > > > > > > > > > This is a forwarded message > From: Marco Schmidt > To: ncc-announce at ripe.net > Date: Friday, April 29, 2016, 11:18:23 AM > Subject: [ncc-announce] [news] RIPE Policy Proposals - April Update > > > ===8<==============Original message text=============== > Dear colleagues, > > Here is our monthly overview of open policy proposals and their stage in > the RIPE Policy Development Process (PDP). > > If you wish to join the discussion about a particular proposal, please > do so on the relevant working group mailing list. > > Proposals Open for Discussion: > 2015-05, "Revision of Last /8 Allocation Criteria" > > Proposals Awaiting Input: > 2015-04, "RIPE Resource Transfer Policies" > 2016-01, "Include Legacy Internet Resource Holders in the Abuse-c Policy" > > > Proposal Overviews: > > PROPOSAL: 2015-05, "Revision of Last /8 Allocation Criteria" > OVERVIEW: Aims to allow LIRs to request an additional /22 IPv4 > allocation from the RIPE NCC every 18 months. The latest version of the > proposal suggests several requirements, such as the LIR cannot hold more > than a /20 IPv4, must document their IPv6 deployment and has not > transferred any IPv4 address space before. > STATUS: Discussion Phase > WHERE TO COMMENT: Address Policy Working Group: address-policy-wg at ripe.net > DEADLINE: 13 May 2016 > FULL PROPOSAL: https://www.ripe.net/participate/policies/proposals/2015-05 > > ===== > > The following proposals are awaiting input before they can go any > further in the PDP. > > PROPOSAL: 2015-04, "RIPE Resource Transfer Policies" > OVERVIEW: Aims to create a single transfer policy with all relevant > information on the transfer of Internet number resources, replacing text > in several RIPE Policies. The proposal also introduces a 24-month > holding period for IPv4 addresses and 16-bit ASNs after any change of > holdership. > RIPE NCC IMPACT ANALYSIS: Includes the point how the 24-month holding > period for scarce resources will be applied. > STATUS: Review Phase ? Awaiting decision from working group chair > FULL PROPOSAL: https://www.ripe.net/participate/policies/proposals/2015-04 > > PROPOSAL: 2016-01, "Include Legacy Internet Resource Holders in the > Abuse-c Policy" > OVERVIEW: Aims for a mandatory abuse contact for Legacy Internet > Resource holders in the RIPE Database. > STATUS: Discussion Phase ? Awaiting decision from proposer > FULL PROPOSAL: https://www.ripe.net/participate/policies/proposals/2016-01 > > > The RIPE NCC provides an overview of current RIPE Policy Proposals on > www.ripe.net: > https://www.ripe.net/participate/policies/current-proposals/current-policy-proposals > > We look forward to your involvement in the PDP. > > Kind regards, > > Marco Schmidt > RIPE Policy Development Officer > RIPE NCC > > > > ===8<===========End of original message text=========== > > > > -- Ing. Riccardo Gori e-mail: rgori at wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info at wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logoWirem_4cm_conR.jpg Type: image/jpeg Size: 41774 bytes Desc: not available URL: From mostafa.shahdadi at gmail.com Sat Apr 30 07:41:47 2016 From: mostafa.shahdadi at gmail.com (mostafa shahdadi) Date: Sat, 30 Apr 2016 10:11:47 +0430 Subject: [address-policy-wg] (no subject) Message-ID: -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: From rgori at wirem.net Sat Apr 30 17:41:04 2016 From: rgori at wirem.net (Riccardo Gori) Date: Sat, 30 Apr 2016 17:41:04 +0200 Subject: [address-policy-wg] Fwd: [ncc-announce] [news] RIPE Policy Proposals - April Update In-Reply-To: <52493449.20160430122949@itns.md> References: <572318CF.6020601@ripe.net> <194432980.20160429113800@itns.md> <7d770256-c3ee-f43d-009f-c1fe8337167e@wirem.net> <52493449.20160430122949@itns.md> Message-ID: <6a881e1c-1f23-4331-92fc-4c18d3008206@wirem.net> Hi Sergiu, thank you for your reply. I don't get if you disagree with current policy or proposed one. Anyway: The LIR that assisgned or allocated the first /22 to your current new LIR can transfert the space once 24 months are passed. This is the holding time before a transfert can take place standing on current policies. 2015-05 policy proposal won't change this aspect. kind regards Riccardo Il 30/04/2016 11:29, Sergiu IANCIUC ha scritto: > Re[2]: [address-policy-wg] Fwd: [ncc-announce] [news] RIPE Policy > Proposals - April Update > > salut Riccardo, > > > I do not totally agree with you.. and I explain why. > > > you are talking about the case in the future.. but I give an actual > example.. > > > 2 years ago my company has an allocated prefix from a LIR. After 1 > year we asked additional resources and had a negative response because > of the RIPE Policy limitations. after the next year the situation was > the same and to receive an additional prefix we became LIR. Now, pls > answer... why to not permit transfer from the old LIR to the new one > if they agree on it and do it for ensure the new LIR in continuity of > the prefix use (all this with condition that this prefix was allocated > by the old LIR when the new LIR has the status OTHER). > > > > > Best Regards, > > > - > > Sergiu IANCIUC > > SC ITNS.NET SRL > > > MD-2068, Moldova > > or. Chisinau, str. Miron Costin 3/1 > > tel.: +373 22 877 877 > > fax : +373 22 44 11 73 > > mobile: +373 690 22 111 > > url: http://www.itns.md > > > Save a tree... Don't print this email unless you have to... > > > > > > Saturday, April 30, 2016, 8:33:49 AM, you wrote: > > > > > > Dear Sergiu, > > about your example and its eventual realtionship with the proposal > 2015-05: > > Company X would have not limit in receive address space as described > in transfert or allocation policies. > > The limit described in 2015-05 would be applied to the LIR that > assigned space to Company X and, as described in your example, later > transfered the space in Company X registry. > > This LIR is supposed to not need address space as it moved it outside > its registry so it would not be able to request an additional /22 > allocation from pool outside 185/8 standing on 2015-05 proposal > > > On the other hand if Company X after its sing up as a new LIR after 18 > months need more space and there is enough space outside 185/8 would > be able to request an additional /22 standing on 2015-05 proposal. > The LIR that offered the first /22 to Company X as "assigned > resource" could also request an additional /22 allocation if its > registry is holding less than a /20 IPv4. > > > hope this help > > regards > > Riccardo > > > Il 29/04/2016 10:38, Sergiu IANCIUC ha scritto: > > hello, > > > PLS, take in consideration the situation > > > Company X has a /22 from its LIR. The LIR can not offer more IPv4 > > spaces and the Company X becomes a LIR to satisfy its needs. Now, it > > is logical that the LIR (if agreed between these 2 LIRs) transfers the > > space allocated to the Company X (now the new LIR) AND THIS have to > > not be the part from the policy - > > > "requirements, such as the LIR has not transferred any IPv4 address > > space before." > > > What are you thinking about? > > > > Best Regards, > > > > - > > Sergiu IANCIUC > > SC ITNS.NET SRL > > > > MD-2068, Moldova > > or. Chisinau, str. Miron Costin 3/1 > > tel.: +373 22 877 877 > > fax : +373 22 44 11 73 > > mobile: +373 690 22 111 > > url: http://www.itns.md > > > > Save a tree... Don't print this email unless you have to... > > > > > > > > > > This is a forwarded message > > From: Marco Schmidt > > To: ncc-announce at ripe.net > > Date: Friday, April 29, 2016, 11:18:23 AM > > Subject: [ncc-announce] [news] RIPE Policy Proposals - April Update > > > > ===8<==============Original message text=============== > > Dear colleagues, > > > Here is our monthly overview of open policy proposals and their stage in > > the RIPE Policy Development Process (PDP). > > > If you wish to join the discussion about a particular proposal, please > > do so on the relevant working group mailing list. > > > Proposals Open for Discussion: > > 2015-05, "Revision of Last /8 Allocation Criteria" > > > Proposals Awaiting Input: > > 2015-04, "RIPE Resource Transfer Policies" > > 2016-01, "Include Legacy Internet Resource Holders in the Abuse-c Policy" > > > > Proposal Overviews: > > > PROPOSAL: 2015-05, "Revision of Last /8 Allocation Criteria" > > OVERVIEW: Aims to allow LIRs to request an additional /22 IPv4 > > allocation from the RIPE NCC every 18 months. The latest version of the > > proposal suggests several requirements, such as the LIR cannot hold more > > than a /20 IPv4, must document their IPv6 deployment and has not > > transferred any IPv4 address space before. > > STATUS: Discussion Phase > > WHERE TO COMMENT: Address Policy Working Group: > address-policy-wg at ripe.net > > DEADLINE: 13 May 2016 > > FULL PROPOSAL: https://www.ripe.net/participate/policies/proposals/2015-05 > > > ===== > > > The following proposals are awaiting input before they can go any > > further in the PDP. > > > PROPOSAL: 2015-04, "RIPE Resource Transfer Policies" > > OVERVIEW: Aims to create a single transfer policy with all relevant > > information on the transfer of Internet number resources, replacing text > > in several RIPE Policies. The proposal also introduces a 24-month > > holding period for IPv4 addresses and 16-bit ASNs after any change of > > holdership. > > RIPE NCC IMPACT ANALYSIS: Includes the point how the 24-month holding > > period for scarce resources will be applied. > > STATUS: Review Phase ? Awaiting decision from working group chair > > FULL PROPOSAL: https://www.ripe.net/participate/policies/proposals/2015-04 > > > PROPOSAL: 2016-01, "Include Legacy Internet Resource Holders in the > > Abuse-c Policy" > > OVERVIEW: Aims for a mandatory abuse contact for Legacy Internet > > Resource holders in the RIPE Database. > > STATUS: Discussion Phase ? Awaiting decision from proposer > > FULL PROPOSAL: https://www.ripe.net/participate/policies/proposals/2016-01 > > > > The RIPE NCC provides an overview of current RIPE Policy Proposals on > www.ripe.net > :https://www.ripe.net/participate/policies/current-proposals/current-policy-proposals > > > We look forward to your involvement in the PDP. > > > Kind regards, > > > Marco Schmidt > > RIPE Policy Development Officer > > RIPE NCC > > > > > ===8<===========End of original message text=========== > > > > > > > > -- > > > Ing. Riccardo Gori > > e-mail: rgori at wirem.net > > Mobile: +39 339 8925947 > > Mobile: +34 602 009 437 > > Profile: https://it.linkedin.com/in/riccardo-gori-74201943 > > WIREM Fiber Revolution > > Net-IT s.r.l. > > Via Cesare Montanari, 2 > > 47521 Cesena (FC) > > Tel +39 0547 1955485 > > Fax +39 0547 1950285 > > > -------------------------------------------------------------------- > > CONFIDENTIALITY NOTICE > > This message and its attachments are addressed solely to the persons > > above and may contain confidential information. If you have received > > the message in error, be informed that any use of the content hereof > > is prohibited. Please return it immediately to the sender and delete > > the message. Should you have any questions, please contact us by re- > > plying to info at wirem.net > > Thank you > > WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) > > -------------------------------------------------------------------- > -- Ing. Riccardo Gori e-mail: rgori at wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info at wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logoWirem_4cm_conR.jpg Type: image/jpeg Size: 41774 bytes Desc: not available URL: From rgori at wirem.net Sat Apr 30 22:52:14 2016 From: rgori at wirem.net (Riccardo Gori) Date: Sat, 30 Apr 2016 22:52:14 +0200 Subject: [address-policy-wg] Fwd: [ncc-announce] [news] RIPE Policy Proposals - April Update In-Reply-To: <1005021206.20160430201521@itns.md> References: <572318CF.6020601@ripe.net> <194432980.20160429113800@itns.md> <7d770256-c3ee-f43d-009f-c1fe8337167e@wirem.net> <52493449.20160430122949@itns.md> <6a881e1c-1f23-4331-92fc-4c18d3008206@wirem.net> <1005021206.20160430201521@itns.md> Message-ID: Hi Sergiu, Il 30/04/2016 19:15, Sergiu IANCIUC ha scritto: > Re[2]: [address-policy-wg] Fwd: [ncc-announce] [news] RIPE Policy > Proposals - April Update > > salut Riccardo, > > > 1. I propose that here - > > > Proposals Open for Discussion: > > 2015-05, "Revision of Last /8 Allocation Criteria" > > > Proposal Overviews: > > > PROPOSAL: 2015-05, "Revision of Last /8 Allocation Criteria" > > OVERVIEW: Aims to allow LIRs to request an additional /22 IPv4 > > allocation from the RIPE NCC every 18 months. The latest version of the > > proposal suggests several requirements, such as the LIR cannot hold more > > than a /20 IPv4, must document their IPv6 deployment and has not > > transferred any IPv4 address space before. > > STATUS: Discussion Phase > > WHERE TO COMMENT: Address Policy Working Group: > address-policy-wg at ripe.net > > DEADLINE: 13 May 2016 > > FULL PROPOSAL: https://www.ripe.net/participate/policies/proposals/2015-05 > > > to be introduced a definition that includes in the " has not > > transferred any IPv4 address space before" list the LIR that > transferred a prefix to an other LIR if this prefix was allocated to > the receiving LIR when it was not the RIPE NCC member/LIR. > If I understand well your point this is already a requirement in 2015-05. Please have a look to the full proposal at https://www.ripe.net/participate/policies/proposals/2015-05 point [...] "3.1. The LIR has not transferred any IPv4 address space to another LIR, a member of another RIR, or an End User." [...] > > > 2. explain pls what does it signify > > > The latest version of the proposal suggests several requirements, such > as the LIR cannot hold more than a /20 IPv4 > > > cannot hold more then /20 unused ? > Doesn't matter if the /20 is used or not. With current text of the 2015-05 if an LIR already holds up to a /20 could not request any additional allocation from available pool outside 185/8. If he didn't request a last /22 from 185/8 he can request it at any time. Feel free to give the list your opinion about supporting 2015-05 or not. thank you for your interest kind regards Riccardo > > > > > > Best Regards, > > > - > > Sergiu IANCIUC > > SC ITNS.NET SRL > > > MD-2068, Moldova > > or. Chisinau, str. Miron Costin 3/1 > > tel.: +373 22 877 877 > > fax : +373 22 44 11 73 > > mobile: +373 690 22 111 > > url: http://www.itns.md > > > Save a tree... Don't print this email unless you have to... > > > > > > Saturday, April 30, 2016, 6:41:04 PM, you wrote: > > > > > > Hi Sergiu, > > > thank you for your reply. I don't get if you disagree with current > policy or proposed one. > > Anyway: > > The LIR that assisgned or allocated the first /22 to your current new > LIR can transfert the space once 24 months are passed. > > This is the holding time before a transfert can take place standing on > current policies. > > 2015-05 policy proposal won't change this aspect. > > > kind regards > > Riccardo > > > > Il 30/04/2016 11:29, Sergiu IANCIUC ha scritto: > > salut Riccardo, > > > I do not totally agree with you.. and I explain why. > > > you are talking about the case in the future.. but I give an actual > example.. > > > 2 years ago my company has an allocated prefix from a LIR. After 1 > year we asked additional resources and had a negative response because > of the RIPE Policy limitations. after the next year the situation was > the same and to receive an additional prefix we became LIR. Now, pls > answer... why to not permit transfer from the old LIR to the new one > if they agree on it and do it for ensure the new LIR in continuity of > the prefix use (all this with condition that this prefix was allocated > by the old LIR when the new LIR has the status OTHER). > > > > > Best Regards, > > > - > > Sergiu IANCIUC > > SC ITNS.NET SRL > > > MD-2068, Moldova > > or. Chisinau, str. Miron Costin 3/1 > > tel.: +373 22 877 877 > > fax : +373 22 44 11 73 > > mobile: +373 690 22 111 > > url: http://www.itns.md > > > Save a tree... Don't print this email unless you have to... > > > > > > Saturday, April 30, 2016, 8:33:49 AM, you wrote: > > > > > > Dear Sergiu, > > about your example and its eventual realtionship with the proposal > 2015-05: > > Company X would have not limit in receive address space as described > in transfert or allocation policies. > > The limit described in 2015-05 would be applied to the LIR that > assigned space to Company X and, as described in your example, later > transfered the space in Company X registry. > > This LIR is supposed to not need address space as it moved it outside > its registry so it would not be able to request an additional /22 > allocation from pool outside 185/8 standing on 2015-05 proposal > > > On the other hand if Company X after its sing up as a new LIR after 18 > months need more space and there is enough space outside 185/8 would > be able to request an additional /22 standing on 2015-05 proposal. > The LIR that offered the first /22 to Company X as "assigned > resource" could also request an additional /22 allocation if its > registry is holding less than a /20 IPv4. > > > hope this help > > regards > > Riccardo > > > Il 29/04/2016 10:38, Sergiu IANCIUC ha scritto: > > hello, > > > PLS, take in consideration the situation > > > Company X has a /22 from its LIR. The LIR can not offer more IPv4 > > spaces and the Company X becomes a LIR to satisfy its needs. Now, it > > is logical that the LIR (if agreed between these 2 LIRs) transfers the > > space allocated to the Company X (now the new LIR) AND THIS have to > > not be the part from the policy - > > > "requirements, such as the LIR has not transferred any IPv4 address > > space before." > > > What are you thinking about? > > > > Best Regards, > > > > - > > Sergiu IANCIUC > > SC ITNS.NET SRL > > > > MD-2068, Moldova > > or. Chisinau, str. Miron Costin 3/1 > > tel.: +373 22 877 877 > > fax : +373 22 44 11 73 > > mobile: +373 690 22 111 > > url: http://www.itns.md > > > > Save a tree... Don't print this email unless you have to... > > > > > > > > > > This is a forwarded message > > From: Marco Schmidt > > To: ncc-announce at ripe.net > > Date: Friday, April 29, 2016, 11:18:23 AM > > Subject: [ncc-announce] [news] RIPE Policy Proposals - April Update > > > > ===8<==============Original message text=============== > > Dear colleagues, > > > Here is our monthly overview of open policy proposals and their stage in > > the RIPE Policy Development Process (PDP). > > > If you wish to join the discussion about a particular proposal, please > > do so on the relevant working group mailing list. > > > Proposals Open for Discussion: > > 2015-05, "Revision of Last /8 Allocation Criteria" > > > Proposals Awaiting Input: > > 2015-04, "RIPE Resource Transfer Policies" > > 2016-01, "Include Legacy Internet Resource Holders in the Abuse-c Policy" > > > > Proposal Overviews: > > > PROPOSAL: 2015-05, "Revision of Last /8 Allocation Criteria" > > OVERVIEW: Aims to allow LIRs to request an additional /22 IPv4 > > allocation from the RIPE NCC every 18 months. The latest version of the > > proposal suggests several requirements, such as the LIR cannot hold more > > than a /20 IPv4, must document their IPv6 deployment and has not > > transferred any IPv4 address space before. > > STATUS: Discussion Phase > > WHERE TO COMMENT: Address Policy Working Group: > address-policy-wg at ripe.net > > DEADLINE: 13 May 2016 > > FULL PROPOSAL: https://www.ripe.net/participate/policies/proposals/2015-05 > > > ===== > > > The following proposals are awaiting input before they can go any > > further in the PDP. > > > PROPOSAL: 2015-04, "RIPE Resource Transfer Policies" > > OVERVIEW: Aims to create a single transfer policy with all relevant > > information on the transfer of Internet number resources, replacing text > > in several RIPE Policies. The proposal also introduces a 24-month > > holding period for IPv4 addresses and 16-bit ASNs after any change of > > holdership. > > RIPE NCC IMPACT ANALYSIS: Includes the point how the 24-month holding > > period for scarce resources will be applied. > > STATUS: Review Phase ? Awaiting decision from working group chair > > FULL PROPOSAL: https://www.ripe.net/participate/policies/proposals/2015-04 > > > PROPOSAL: 2016-01, "Include Legacy Internet Resource Holders in the > > Abuse-c Policy" > > OVERVIEW: Aims for a mandatory abuse contact for Legacy Internet > > Resource holders in the RIPE Database. > > STATUS: Discussion Phase ? Awaiting decision from proposer > > FULL PROPOSAL: https://www.ripe.net/participate/policies/proposals/2016-01 > > > > The RIPE NCC provides an overview of current RIPE Policy Proposals on > www.ripe.net > :https://www.ripe.net/participate/policies/current-proposals/current-policy-proposals > > > We look forward to your involvement in the PDP. > > > Kind regards, > > > Marco Schmidt > > RIPE Policy Development Officer > > RIPE NCC > > > > > ===8<===========End of original message text=========== > > > > > > > > -- > > > Ing. Riccardo Gori > > e-mail: rgori at wirem.net > > Mobile: +39 339 8925947 > > Mobile: +34 602 009 437 > > Profile: https://it.linkedin.com/in/riccardo-gori-74201943 > > WIREM Fiber Revolution > > Net-IT s.r.l. > > Via Cesare Montanari, 2 > > 47521 Cesena (FC) > > Tel +39 0547 1955485 > > Fax +39 0547 1950285 > > > -------------------------------------------------------------------- > > CONFIDENTIALITY NOTICE > > This message and its attachments are addressed solely to the persons > > above and may contain confidential information. If you have received > > the message in error, be informed that any use of the content hereof > > is prohibited. Please return it immediately to the sender and delete > > the message. Should you have any questions, please contact us by re- > > plying to info at wirem.net > > Thank you > > WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) > > -------------------------------------------------------------------- > > > > -- > > > Ing. Riccardo Gori e-mail: rgori at wirem.net > Mobile: +39 339 8925947 Mobile: +34 602 009 > 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 > > WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 > Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 > -------------------------------------------------------------------- > CONFIDENTIALITY NOTICE This message and its attachments are addressed > solely to the persons above and may contain confidential information. > If you have received the message in error, be informed that any use of > the content hereof is prohibited. Please return it immediately to the > sender and delete the message. Should you have any questions, please > contact us by re- plying to info at wirem.net > Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 > Cesena (FC) > -------------------------------------------------------------------- > -- Ing. Riccardo Gori e-mail: rgori at wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info at wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logoWirem_4cm_conR.jpg Type: image/jpeg Size: 41774 bytes Desc: not available URL: From sergiu.ianciuc at itns.md Sat Apr 30 11:29:49 2016 From: sergiu.ianciuc at itns.md (Sergiu IANCIUC) Date: Sat, 30 Apr 2016 12:29:49 +0300 Subject: [address-policy-wg] Fwd: [ncc-announce] [news] RIPE Policy Proposals - April Update In-Reply-To: <7d770256-c3ee-f43d-009f-c1fe8337167e@wirem.net> References: <572318CF.6020601@ripe.net> <194432980.20160429113800@itns.md> <7d770256-c3ee-f43d-009f-c1fe8337167e@wirem.net> Message-ID: <52493449.20160430122949@itns.md> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logoWirem_4cm_conR.jpg Type: image/jpeg Size: 41774 bytes Desc: not available URL: From sergiu.ianciuc at itns.md Sat Apr 30 19:15:21 2016 From: sergiu.ianciuc at itns.md (Sergiu IANCIUC) Date: Sat, 30 Apr 2016 20:15:21 +0300 Subject: [address-policy-wg] Fwd: [ncc-announce] [news] RIPE Policy Proposals - April Update In-Reply-To: <6a881e1c-1f23-4331-92fc-4c18d3008206@wirem.net> References: <572318CF.6020601@ripe.net> <194432980.20160429113800@itns.md> <7d770256-c3ee-f43d-009f-c1fe8337167e@wirem.net> <52493449.20160430122949@itns.md> <6a881e1c-1f23-4331-92fc-4c18d3008206@wirem.net> Message-ID: <1005021206.20160430201521@itns.md> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logoWirem_4cm_conR.jpg Type: image/jpeg Size: 41774 bytes Desc: not available URL: