From mschmidt at ripe.net Wed Sep 13 15:02:07 2017 From: mschmidt at ripe.net (Marco Schmidt) Date: Wed, 13 Sep 2017 15:02:07 +0200 Subject: [address-policy-wg] 2017-01 Policy Proposal Withdrawn (Publish statistics on Intra-RIR Legacy updates) Message-ID: Dear colleagues, The policy proposal 2017-01, "Publish statistics on Intra-RIR Legacy updates" has been withdrawn. The proposal is archived and can be found at: https://www.ripe.net/participate/policies/archived-policy-proposals/archive-policy-proposals/ Reason for withdrawal: The proposer didn't see enough community support, especially from Legacy Resource Holders as the parties that would be most affected. Regards Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From mschmidt at ripe.net Thu Sep 21 13:43:21 2017 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 21 Sep 2017 13:43:21 +0200 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) Message-ID: Dear colleagues, A new RIPE Policy proposal, 2017-03, "Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space", is now available for discussion. The goal of this proposal is to reduce the IPv4 allocations made by the RIPE NCC to a /24 (currently a /22) and only to LIRs that have not received an IPv4 allocation directly from the RIPE NCC before. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2017-03/ As per the RIPE Policy Development Process (PDP), the purpose of this four-week Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposer, with the agreement of the RIPE Working Group Chairs, decides how to proceed with the proposal. We encourage you to review this proposal and send your comments to before 20 October 2017. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From aled.w.morris at googlemail.com Thu Sep 21 14:33:55 2017 From: aled.w.morris at googlemail.com (Aled Morris) Date: Thu, 21 Sep 2017 13:33:55 +0100 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: Message-ID: On 21 September 2017 at 12:43, Marco Schmidt wrote: > > The goal of this proposal is to reduce the IPv4 allocations made by the > RIPE NCC > to a /24 (currently a /22) and only to LIRs that have not received an IPv4 > allocation > directly from the RIPE NCC before. > At the current run-rate, do we know what is the expected expiry of the free pool in RIPE's hands? Aled -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at foobar.org Thu Sep 21 16:00:40 2017 From: nick at foobar.org (Nick Hilliard) Date: Thu, 21 Sep 2017 15:00:40 +0100 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: Message-ID: <59C3C608.8050009@foobar.org> Marco Schmidt wrote: > The goal of this proposal is to reduce the IPv4 allocations made by the RIPE NCC > to a /24 (currently a /22) and only to LIRs that have not received an IPv4 allocation > directly from the RIPE NCC before. The rationale for this is to make RIR-allocated ipv4 address space string out a bit longer by raising the price and dropping the size. The rationale says: > Allowing or encouraging intentional run-out of IPv4 addresses is an > abrogation of the RIPE community's responsibility. Any measures that > can be taken to postpone this point in time should be seen as > critical. It is not convincing to state that allocating /22s instead of /24s is an abrogation of responsibility, and as a community we should step back from this sort of overly dramatic language. A more sober viewpoint is that any future decision about tweaking the balance between allocation size and anticipated run-out time is not much more than an exercise in deck-chair rearrangement. It's a deck-chair rearrangement because the ship is going down and nothing can stop it. The proposal fails to mention the windfall that will ensue for existing address holders as the baseline RIR price for IPv4 addresses will increase from around ?4.70 to nearly ?19. There is no implication here that any of the authors has any self-interest in terms of proposing this sort of policy change, but there are quite a few people in this WG who would be happy with this sort of change, both brokers and incumbent address holders. Because of this, we also need to consider as a community what part self-interested financial motivation is going to play in terms of whether people are going to support this proposal or not, and how compatible this is with good governance of the policy-making mechanism for global resource allocation. The policy proposal also only skirts the issue of the cost of making this change to the Internet core. The remaining pool of 0.66 * /8 is ~11k /22s or ~43k /24s. If, as this proposal suggests, we move from a minimum routable range of /24 to /25 or longer, this is a change that comes at a cost in terms of reducing the lifetime of any routing device on the internet which takes a full dfz. On the flip side, we also need to consider how important this policy is in absolute terms. This is quantifiable because it affects 0.66 of a single /8, which is 0.3% of the entire IANA-allocated ipv4 address space. There are single early-adopter organisations out there who, if they decided to rationalise their address space, would have an effect on ipv4 depletion far in excess of any policy change that the RIPE community could make. Overall, I don't see a compelling case to make this change. Nick From randy at psg.com Thu Sep 21 16:18:21 2017 From: randy at psg.com (Randy Bush) Date: Thu, 21 Sep 2017 23:18:21 +0900 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <59C3C608.8050009@foobar.org> References: <59C3C608.8050009@foobar.org> Message-ID: > The rationale for this is to make RIR-allocated ipv4 address space > string out a bit longer by raising the price and dropping the size. did it say anything about price? i missed that? i did not think the AP WG dealt with pricing; so it would be pretty strange. > It is not convincing to state that allocating /22s instead of /24s is an > abrogation of responsibility, and as a community we should step back > from this sort of overly dramatic language. in an american dictionary, 'abrogation' ranges from lack of awareness to more intentional acts. in this proposal, it was used in relation to the occasional proposal to encourage ipv4 runout to promote ipv6, which should be able to sell on it's own merits, not schadenfreude > A more sober viewpoint is that any future decision about tweaking the > balance between allocation size and anticipated run-out time is not > much more than an exercise in deck-chair rearrangement. It's a > deck-chair rearrangement because the ship is going down and nothing > can stop it. agreed. but we can postpone the inevitable so folk have time to get in the lifeboats. and if we can, as stewards, we have a responsibility to do so. > The proposal fails to mention the windfall that will ensue for existing > address holders as the baseline RIR price for IPv4 addresses will > increase from around ?4.70 to nearly ?19. truth is, i have not modeled what might happen to the ipv4 market. > there are quite a few people in this WG who would be happy with this > sort of change, both brokers and incumbent address holders. and they are evil so should not allowed to be happy? :) > Because of this, we also need to consider as a community what part > self-interested financial motivation is going to play in terms of > whether people are going to support this proposal or not, and how > compatible this is with good governance of the policy-making mechanism > for global resource allocation. i am not sure that the community remains sober enough to do so without getting nasty. i would how so, but my faith wavers. > If, as this proposal suggests, we move from a minimum routable range > of /24 to /25 or longer, this is a change that comes at a cost in > terms of reducing the lifetime of any routing device on the internet > which takes a full dfz. indeed. but i see it as inevitable as the need to bridge becomes more and more intense. so do we want to do it in a controlled and managed fashion or chaotically? randy From ximaera at gmail.com Thu Sep 21 16:23:35 2017 From: ximaera at gmail.com (Artyom Gavrichenkov) Date: Thu, 21 Sep 2017 17:23:35 +0300 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <59C3C608.8050009@foobar.org> References: <59C3C608.8050009@foobar.org> Message-ID: To quote from the document: "Q: How would folk announce longer prefixes for DDoS protection? Mitigation/counter-argument: As operators accept /24s today, when the allocation size is a /22, it might be wise to accept prefixes longer than a /24 when the allocation size is /24. Of course, this would be in the well-documented address range(s) where /24s are allocated." -- okay, this is fine... wait... "Summary of Proposal [..]If the minimum globally-routable prefix changes from a /24 to a smaller prefix, the initial IPv4 allocation should also change to match." -- so, how do those things match? The issue about announcing longer prefixes is one hundred percent correct. As of now, reducing the initial allocation to /24 renders newcomers unable to make use of trivial BGP failover mechanisms. I'd support the idea, but no earlier than the minimum globally-routable IPv4 prefix is changed to /25. Or, to say, initial allocation might be /25 if the MGRP will be /26. | Artyom Gavrichenkov | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191 | mailto: ximaera at gmail.com | fb: ximaera | telegram: xima_era | skype: xima_era | tel. no: +7 916 515 49 58 From tom.hill at bytemark.co.uk Thu Sep 21 16:26:05 2017 From: tom.hill at bytemark.co.uk (Tom Hill) Date: Thu, 21 Sep 2017 15:26:05 +0100 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: <59C3C608.8050009@foobar.org> Message-ID: <6ccee8bc-a770-8457-9a44-851ac73ad91e@bytemark.co.uk> On 21/09/17 15:18, Randy Bush wrote: > indeed. but i see it as inevitable as the need to bridge becomes more > and more intense. so do we want to do it in a controlled and managed > fashion or chaotically? Over half of the table is made-up of /24s; that is not a coincidence. If any new "standard" is chosen for the minimum visible prefix size, you can bet all of those /24 announcements will start turning into a lot more /25 announcements very quickly. "But otherwise I'm liable to hijack!", ad infinitum. I dunno about you, but I can see a lot of operators not being too happy with a ~25% increase in the number of prefixes they're storing in TCAM. -- Tom Hill Network Manager Bytemark Hosting http://www.bytemark.co.uk/ tel. +44 1904 890 890 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From tjc at ecs.soton.ac.uk Thu Sep 21 16:34:50 2017 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Thu, 21 Sep 2017 15:34:50 +0100 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: Message-ID: > On 21 Sep 2017, at 13:33, Aled Morris wrote: > > On 21 September 2017 at 12:43, Marco Schmidt wrote: > The goal of this proposal is to reduce the IPv4 allocations made by the RIPE NCC > to a /24 (currently a /22) and only to LIRs that have not received an IPv4 allocation > directly from the RIPE NCC before. > > At the current run-rate, do we know what is the expected expiry of the free pool in RIPE's hands? There?s http://www.potaroo.net/tools/ipv4/. Tim From nick at foobar.org Thu Sep 21 17:01:35 2017 From: nick at foobar.org (Nick Hilliard) Date: Thu, 21 Sep 2017 16:01:35 +0100 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: <59C3C608.8050009@foobar.org> Message-ID: <59C3D44F.3060809@foobar.org> Randy Bush wrote: > did it say anything about price? i missed that? i did not think > the AP WG dealt with pricing; so it would be pretty strange. You're correct in saying that APWG does not deal with pricing, but it's a bit jesuitical not to acknowledge that the practical impact of this policy change will be a dramatic increase in RIR-allocated ipv4 addresses. > but we can postpone the inevitable so folk have time to get in > the lifeboats. There is no amount of time that will be enough. > so do we want to do it in a controlled and managed fashion or > chaotically? I genuinely don't think that this proposal will impact much on this either way. Nick From sebastian at karotte.org Thu Sep 21 17:56:52 2017 From: sebastian at karotte.org (Sebastian Wiesinger) Date: Thu, 21 Sep 2017 17:56:52 +0200 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <6ccee8bc-a770-8457-9a44-851ac73ad91e@bytemark.co.uk> References: <59C3C608.8050009@foobar.org> <6ccee8bc-a770-8457-9a44-851ac73ad91e@bytemark.co.uk> Message-ID: <20170921155652.nllujn73jzismgji@danton.fire-world.de> * Tom Hill [2017-09-21 16:27]: > Over half of the table is made-up of /24s; that is not a coincidence. > > If any new "standard" is chosen for the minimum visible prefix size, you > can bet all of those /24 announcements will start turning into a lot > more /25 announcements very quickly. > > "But otherwise I'm liable to hijack!", ad infinitum. > > I dunno about you, but I can see a lot of operators not being too happy > with a ~25% increase in the number of prefixes they're storing in TCAM. I think getting the DFZ to lower the minimum prefix size from a /24 is nothing more than wishful thinking. I would bet that IPv4 will run out completely before that happens. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant From randy at psg.com Thu Sep 21 21:18:51 2017 From: randy at psg.com (Randy Bush) Date: Fri, 22 Sep 2017 04:18:51 +0900 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <59C3D44F.3060809@foobar.org> References: <59C3C608.8050009@foobar.org> <59C3D44F.3060809@foobar.org> Message-ID: > You're correct in saying that APWG does not deal with pricing, but > it's a bit jesuitical not to acknowledge that the practical impact of > this policy change will be a dramatic increase in RIR-allocated ipv4 > addresses. someone wrote to me saying the same thing. but they added that the current situation has ripe selling a public good at radically below market pricing and that this has resulted in some very asocial behavior with bad long term effects. >> but we can postpone the inevitable so folk have time to get in >> the lifeboats. > There is no amount of time that will be enough. yes. but v6 is slowly catching on, and we do what we can to make the internet a better place. there is no perfect. randy From randy at psg.com Thu Sep 21 21:22:30 2017 From: randy at psg.com (Randy Bush) Date: Fri, 22 Sep 2017 04:22:30 +0900 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <6ccee8bc-a770-8457-9a44-851ac73ad91e@bytemark.co.uk> References: <59C3C608.8050009@foobar.org> <6ccee8bc-a770-8457-9a44-851ac73ad91e@bytemark.co.uk> Message-ID: > Over half of the table is made-up of /24s; that is not a coincidence. once it was /19. welcome to life. randy From arash_mpc at parsun.com Fri Sep 22 02:21:10 2017 From: arash_mpc at parsun.com (Arash Naderpour) Date: Fri, 22 Sep 2017 10:21:10 +1000 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: Message-ID: Hi, I don't see a need to do this change in the policy at the moment. consummation rate is the same as before. Even if there is a need, it could be 3x/24 or /23.why change it from /22 to /24? Arash On Fri, Sep 22, 2017 at 12:34 AM, Tim Chown wrote: > > On 21 Sep 2017, at 13:33, Aled Morris > wrote: > > > > On 21 September 2017 at 12:43, Marco Schmidt wrote: > > The goal of this proposal is to reduce the IPv4 allocations made by the > RIPE NCC > > to a /24 (currently a /22) and only to LIRs that have not received an > IPv4 allocation > > directly from the RIPE NCC before. > > > > At the current run-rate, do we know what is the expected expiry of the > free pool in RIPE's hands? > > There?s http://www.potaroo.net/tools/ipv4/. > > Tim > -------------- next part -------------- An HTML attachment was scrubbed... URL: From swmike at swm.pp.se Fri Sep 22 06:50:17 2017 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 22 Sep 2017 06:50:17 +0200 (CEST) Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: Message-ID: On Thu, 21 Sep 2017, Tim Chown wrote: >> At the current run-rate, do we know what is the expected expiry of the free pool in RIPE's hands? > > There?s http://www.potaroo.net/tools/ipv4/. There is also: https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustion/ipv4-available-pool-graph Looks to me that there is still IPv4 space being returned, the run-rate on 185/8 is constant, we have approximately 4-5 years to go? To me it looks like things are going according to plan, and I don't see any need to change anything. -- Mikael Abrahamsson email: swmike at swm.pp.se From aleksbulgakov at gmail.com Fri Sep 22 07:41:30 2017 From: aleksbulgakov at gmail.com (Aleksey Bulgakov) Date: Fri, 22 Sep 2017 08:41:30 +0300 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: Message-ID: Hi. I think it would be better to allocate /19 or bigger. It helps to go to IPv6 and the problem of IPv4 is resolved automatically. I don't really understand why the NCC tries to prolong the life of the dead patient by means of restrictions such as 2015-01, 2017-03 and others. It seems the NCC wants to earn money due to the IPs become more expensive. So I oppose this proposal. 22 ??? 2017 ?. 7:50 ???????????? "Mikael Abrahamsson" ???????: On Thu, 21 Sep 2017, Tim Chown wrote: At the current run-rate, do we know what is the expected expiry of the free >> pool in RIPE's hands? >> > > There?s http://www.potaroo.net/tools/ipv4/. > There is also: https://www.ripe.net/publications/ipv6-info-centre/about- ipv6/ipv4-exhaustion/ipv4-available-pool-graph Looks to me that there is still IPv4 space being returned, the run-rate on 185/8 is constant, we have approximately 4-5 years to go? To me it looks like things are going according to plan, and I don't see any need to change anything. -- Mikael Abrahamsson email: swmike at swm.pp.se -------------- next part -------------- An HTML attachment was scrubbed... URL: From raymond.jetten at elisa.fi Fri Sep 22 08:08:06 2017 From: raymond.jetten at elisa.fi (Jetten Raymond) Date: Fri, 22 Sep 2017 06:08:06 +0000 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: Message-ID: <41283d552b57473cac29c0b92a82ff4d@elisa.fi> Hello Aleksey, Please read : https://www.ripe.net/participate/policies https://www.ripe.net/about-us/executive-board It is NOT the NCC who makes proposals, it?s the community who makes proposals (anyone interested), and the members together with the board and the budget of the NCC , who decide on pricing. Rgds, Ray From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Aleksey Bulgakov Sent: 22. syyskuuta 2017 8:42 To: RIPE Address Policy WG List Subject: Re: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) Hi. I think it would be better to allocate /19 or bigger. It helps to go to IPv6 and the problem of IPv4 is resolved automatically. I don't really understand why the NCC tries to prolong the life of the dead patient by means of restrictions such as 2015-01, 2017-03 and others. It seems the NCC wants to earn money due to the IPs become more expensive. So I oppose this proposal. 22 ??? 2017 ?. 7:50 ???????????? "Mikael Abrahamsson" > ???????: On Thu, 21 Sep 2017, Tim Chown wrote: At the current run-rate, do we know what is the expected expiry of the free pool in RIPE's hands? There?s http://www.potaroo.net/tools/ipv4/. There is also: https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustion/ipv4-available-pool-graph Looks to me that there is still IPv4 space being returned, the run-rate on 185/8 is constant, we have approximately 4-5 years to go? To me it looks like things are going according to plan, and I don't see any need to change anything. -- Mikael Abrahamsson email: swmike at swm.pp.se -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfriacas at fccn.pt Fri Sep 22 09:04:57 2017 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Fri, 22 Sep 2017 08:04:57 +0100 (WEST) Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: Message-ID: On Fri, 22 Sep 2017, Arash Naderpour wrote: > Hi, Hi, > I don't see a need to do this change in the policy at the moment. > consummation rate is the same as before. This proposal is not aimed at preventing the complete runout. That will happen. This proposal aims to preserve some tiny resources for new entrants in this community, by trying to extend the time period until the runout occurs. We cannot "measure" its benefits until the runout occurs, and we can then count how many new entrants did get a tiny portion of (new, never used before) IPv4 address space. > Even if there is a need, it could be 3x/24 or /23.why change it from /22 to /24? Yes, a /23+/24 or a /23 would be a step in the right direction. If, at global level, a /25 or a /26 was acceptable (routing-wise), then that would be even better. I would also like to draw your attention to the last section about "Alignment with other RIRs": LACNIC already has this in place. ARIN has something, which isn't really exactly the same, but the main goal is very similar. :-) Regards, Carlos Fria?as > Arash > > > > On Fri, Sep 22, 2017 at 12:34 AM, Tim Chown wrote: > > On 21 Sep 2017, at 13:33, Aled Morris wrote: > > > > On 21 September 2017 at 12:43, Marco Schmidt wrote: > > The goal of this proposal is to reduce the IPv4 allocations made by the RIPE NCC > > to a /24 (currently a /22) and only to LIRs that have not received an IPv4 allocation > > directly from the RIPE NCC before. > > > > At the current run-rate, do we know what is the expected expiry of the free pool in RIPE's hands? > > There?s http://www.potaroo.net/tools/ipv4/. > > Tim > > > > From randy at psg.com Fri Sep 22 09:08:01 2017 From: randy at psg.com (Randy Bush) Date: Fri, 22 Sep 2017 16:08:01 +0900 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: Message-ID: > I think it would be better to allocate /19 or bigger. see the section on abrogating our responsibilities for stewardship if ipv6 can not seel itself, all the pressure will do is make even more nats. we don't really want that. oppressing the proletariat did not work out too randy. well From randy at psg.com Fri Sep 22 09:10:37 2017 From: randy at psg.com (Randy Bush) Date: Fri, 22 Sep 2017 16:10:37 +0900 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: Message-ID: > Looks to me that there is still IPv4 space being returned, the > run-rate on 185/8 is constant, we have approximately 4-5 years to go? and you believe that there will be zero desirable ipv4 destinations on the internet by then? sure does not look like it as far as i can see. and if a new entrant needs to reach the remaining ipv4 internet, ...? randy From randy at psg.com Fri Sep 22 09:18:46 2017 From: randy at psg.com (Randy Bush) Date: Fri, 22 Sep 2017 16:18:46 +0900 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: <59C3C608.8050009@foobar.org> Message-ID: a bit of history for those with short term vision 1995, and large providers were running out of ram to hold the table. sprint was the closest to the edge and falling over; but others were not far behind and could smell the coffee. these were the days where we all intimately knew each others' networks. nobody's management was gonna pay to upgrade hundreds of routers. sean had to filter to keep from crashing. others, such as asp and i, were also filtering, as much to keep the table down as to protect from idiots such as vinnie from killing us (7007 incident). so the providers who were concerned and the rirs met at the danvers ietf and agreed to only let /19s and shorter, and swamp space /24s, through if the rirs would please not allocate longer prefixes for a couple of years until routers could be upgraded. rfc 2050 was the result. eventually, like six yesrs later, customers complained enough that the filters had to be removed. when a big customer or two wanted to get to someone with a /24 in old B space, the filters fell. business wins. when v4 runout forces folk to put /28s in frnt of nats, the folk with shiny shoes will have a little chat with senior leadership, and they'll cough up the bucks to hold the routes. history repeats. like the ethernet mfrs tell us that we need to use 4g, 40g, ... instead of 10g, 100g, 1tb, ... life adds zeros. randy From swmike at swm.pp.se Fri Sep 22 09:21:43 2017 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 22 Sep 2017 09:21:43 +0200 (CEST) Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: Message-ID: On Fri, 22 Sep 2017, Randy Bush wrote: >> Looks to me that there is still IPv4 space being returned, the >> run-rate on 185/8 is constant, we have approximately 4-5 years to go? > > and you believe that there will be zero desirable ipv4 destinations on the > internet by then? sure does not look like it as far as i can see. I agree. > and if a new entrant needs to reach the remaining ipv4 internet, ...? Then they have to buy addresses in the market. I keep running into people who claim "look, RIPE is not out of IPv4 addresses, the IPv4 exhaustion is just a hype/FUD". They won't stop until RIPE is really out. If this happens in 4-5 years, I'm fine with that. That means they had 8-10 years from we actually ran out to understand. We (the RIPE community) has had a quite balanced and approach to this and enabled new entrants in the mean time. We can't stretch this out forever. The stone is bled dry, and that's just the way it is. -- Mikael Abrahamsson email: swmike at swm.pp.se From cfriacas at fccn.pt Fri Sep 22 09:23:01 2017 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Fri, 22 Sep 2017 08:23:01 +0100 (WEST) Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: Message-ID: On Fri, 22 Sep 2017, Aleksey Bulgakov wrote: > Hi. Hi, > I think it would be better to allocate /19 or bigger. It helps to go to > IPv6 and the problem of IPv4 is resolved automatically. I'm really not sure about that. It won't solve any new entrant's case. I'm working around IPv6 since 2001. Anna and Randy probably since before that. We have deployed IPv6. It didn't enable us to completely get rid of IPv4 within our networks. That also didn't solve any issue for 3rd party networks -- they all still need IPv4 addresses. > I don't really understand why the NCC tries to prolong the life of the > dead patient by means of restrictions such as 2015-01, 2017-03 and > others. Please note 2017-03 is not approved yet. Please also note that the NCC is not authoring this proposal. There was a presentation about this issue in Budapest at RIPE 72. Randy talked about building a new proposal then, and it took some months to put it together. :-) > It seems the NCC wants to earn money due to the IPs become more > expensive. I don't really think this is the case. The main goal here is to preserve a minimal chunk of space for new entrants. And today, a /24 is the "minimal acceptable" size for that. > So I oppose this proposal. Noted. Regards, Carlos Fria?as > > 22 ???2017 ?.7:50 ???????????? "Mikael Abrahamsson" ???????: > On Thu, 21 Sep 2017, Tim Chown wrote: > > At the current run-rate, do we know what is the expected expiry of the free pool in RIPE's hands? > > > There?s http://www.potaroo.net/tools/ipv4/. > > > There is also: > > https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustion/ipv4-available-pool-graph > > Looks to me that there is still IPv4 space being returned, the run-rate on 185/8 is constant, we have approximately 4-5 years to go? > > To me it looks like things are going according to plan, and I don't see any need to change anything. > > -- > Mikael Abrahamsson? ? email: swmike at swm.pp.se > > > > From randy at psg.com Fri Sep 22 09:35:48 2017 From: randy at psg.com (Randy Bush) Date: Fri, 22 Sep 2017 16:35:48 +0900 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: Message-ID: > Then they have to buy addresses in the market. I keep running into > people who claim "look, RIPE is not out of IPv4 addresses, the IPv4 > exhaustion is just a hype/FUD". people will say all sorts of stupid things; funny monkeys we are. this does not mean we should use technology to teach morality lessons. it has not worked out too well when tried. > They won't stop until RIPE is really out. and of course they will find nothing else to complain about, accuse, try to scam, ... and cash will fall from the sky. randy From arash_mpc at parsun.com Fri Sep 22 09:47:33 2017 From: arash_mpc at parsun.com (Arash Naderpour) Date: Fri, 22 Sep 2017 17:47:33 +1000 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: Message-ID: Hi Carlos, > > This proposal is not aimed at preventing the complete runout. That will > happen. This proposal aims to preserve some tiny resources for new entrants > in this community, by trying to extend the time period until the runout > occurs. We cannot "measure" its benefits until the runout occurs, and we > can then count how many new entrants did get a tiny portion of (new, never > used before) IPv4 address space. The current policy without this change is doing the same, preserving tiny resources (/22) for new entrants. You are saying that there are some benefit and we cannot measure them now, but lets do it, am I right? > Even if there is a need, it could be 3x/24 or /23.why change it from /22 >> to /24? >> > > Yes, a /23+/24 or a /23 would be a step in the right direction. If, at > global level, a /25 or a /26 was acceptable (routing-wise), then that would > be even better. I would also like to draw your attention to the last section about > "Alignment with other RIRs": LACNIC already has this in place. ARIN has > something, which isn't really exactly the same, but the main goal is very > similar. :-) > Still unanswered, why /24 not a /23+/24 or a /23? what is the benefit of this "Alignment with other RIRs" to the RIPE community? I don't see any need for that too. Regards, Arash > Arash >> >> >> >> On Fri, Sep 22, 2017 at 12:34 AM, Tim Chown wrote: >> > On 21 Sep 2017, at 13:33, Aled Morris < >> aled.w.morris at googlemail.com> wrote: >> > >> > On 21 September 2017 at 12:43, Marco Schmidt >> wrote: >> > The goal of this proposal is to reduce the IPv4 allocations made >> by the RIPE NCC >> > to a /24 (currently a /22) and only to LIRs that have not >> received an IPv4 allocation >> > directly from the RIPE NCC before. >> > >> > At the current run-rate, do we know what is the expected expiry >> of the free pool in RIPE's hands? >> >> There?s http://www.potaroo.net/tools/ipv4/. >> >> Tim >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From swmike at swm.pp.se Fri Sep 22 09:53:10 2017 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 22 Sep 2017 09:53:10 +0200 (CEST) Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: Message-ID: On Fri, 22 Sep 2017, Randy Bush wrote: > people will say all sorts of stupid things; funny monkeys we are. this > does not mean we should use technology to teach morality lessons. it > has not worked out too well when tried. My point is that it's useless to prolong the agony. The more we do, the longer people will procrastinate, and the more painful it becomes. /22 is a good tradeoff between the different goals here. It was a good tradeoff when it was implemented, I see it still being a good tradeoff 3 years from now. -- Mikael Abrahamsson email: swmike at swm.pp.se From noc at kwaoo.net Fri Sep 22 09:58:16 2017 From: noc at kwaoo.net (noc at kwaoo.net) Date: Fri, 22 Sep 2017 09:58:16 +0200 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: Message-ID: Maybe the right path is to find some way to allocate those addresses to real new entrants only Perhaps limitations like only one allocation: - per LIR - per legal entity - per physical person - per "network", "activity" or whatever, & based on how you should have your own resources Anything that can allow the RIPE to say : "nope, you're obviously trying to get more stuff from us, you got your part, we deny this allocation" This way, the last ressources' purpose will be filled properly, and not scavenged by greedy guys Regards, On 22/09/2017 09:04, Carlos Fria?as wrote: > This proposal is not aimed at preventing the complete runout. That will > happen. This proposal aims to preserve some tiny resources for new > entrants in this community, by trying to extend the time period until > the runout occurs. We cannot "measure" its benefits until the runout > occurs, and we can then count how many new entrants did get a tiny > portion of (new, never used before) IPv4 address space. -- Jack Net/sys admin More details about KWAOO can be found at: https://as24904.kwaoo.net/ From dominik at clouvider.co.uk Fri Sep 22 10:01:02 2017 From: dominik at clouvider.co.uk (Dominik Nowacki) Date: Fri, 22 Sep 2017 08:01:02 +0000 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: , Message-ID: <5E0B4D95-0F88-4428-8710-676B65E4F785@clouvider.co.uk> I agree with Mikael. It all goes again and again. I don?t see a need to change the current policy. Especially not to reduce the assignment. There has to come a time for the IP4 to finish at RIR level before pressure builds up on Ip6 rollout for those who didn?t bother to date. I don?t believe prolonging this even further serves the interest the community better, it does however serves the interest of brokers and rouge LIRs selling ?Virgin, never used blocks? on the market today by increasing their profits. I?m against this proposal. With Kind Regards, Dominik Nowacki Clouvider Limited is a limited company registered in England and Wales. Registered number: 08750969. Registered office: 88 Wood Street, London, United Kingdom, EC2V 7RS. Please note that Clouvider Limited may monitor email traffic data and also the content of email for the purposes of security and staff training. This message contains confidential information and is intended only for the intended recipient. If you do not believe you are the intended recipient you should not disseminate, distribute or copy this e-mail. Please notify abuse at clouvider.net of this e-mail immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Clouvider Limited nor any of its employees therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. On 22 Sep 2017, at 08:53, Mikael Abrahamsson > wrote: On Fri, 22 Sep 2017, Randy Bush wrote: people will say all sorts of stupid things; funny monkeys we are. this does not mean we should use technology to teach morality lessons. it has not worked out too well when tried. My point is that it's useless to prolong the agony. The more we do, the longer people will procrastinate, and the more painful it becomes. /22 is a good tradeoff between the different goals here. It was a good tradeoff when it was implemented, I see it still being a good tradeoff 3 years from now. -- Mikael Abrahamsson email: swmike at swm.pp.se -------------- next part -------------- An HTML attachment was scrubbed... URL: From danny at danysek.cz Fri Sep 22 10:09:28 2017 From: danny at danysek.cz (Daniel Suchy) Date: Fri, 22 Sep 2017 10:09:28 +0200 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: Message-ID: <397fd725-0403-dca7-539e-1550faa5e0e3@danysek.cz> Hello, /24 is de-facto standard accepted in routing tables these days and also /24 was used in large scale during PI assignments - so I don't see any problem in reduction of initial (minimal) IPv4 allocation. So i support this idea. But I would like to keep option for asking more than /24 (up to /22 maximum, as was decided in the past) LIRs eligible for allocation, if LIR properly documents his request. >From my own practice there're some LIR, where /24 is sufficient and they just become LIRs because there's no other real option to get independent addresses (old "PI") and with /22 we're just wasting limited resource. But there're also LIRs, where /22 will actively used. I don't see any problems in terms of RFC 2050 mentioned here and memory contraints, providers had to upgrade their routers in meantime anyway (at least due to IPv6 adoption). Fragmentation up to /24 is long-term reality and we had to deal with it anyway. With regards, Daniel On 09/21/2017 01:43 PM, Marco Schmidt wrote: > Dear colleagues, > > A new RIPE Policy proposal, 2017-03, "Reducing Initial IPv4 Allocation, > aiming to preserve a minimum of IPv4 space", is now available for discussion. > > The goal of this proposal is to reduce the IPv4 allocations made by the RIPE NCC > to a /24 (currently a /22) and only to LIRs that have not received an IPv4 allocation > directly from the RIPE NCC before. > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2017-03/ > > As per the RIPE Policy Development Process (PDP), the purpose of this > four-week Discussion Phase is to discuss the proposal and provide feedback to the proposer. > > At the end of the Discussion Phase, the proposer, with the agreement of > the RIPE Working Group Chairs, decides how to proceed with the proposal. > > We encourage you to review this proposal and send your comments to > before 20 October 2017. > > Kind regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > From jim at rfc1035.com Fri Sep 22 10:15:08 2017 From: jim at rfc1035.com (Jim Reid) Date: Fri, 22 Sep 2017 09:15:08 +0100 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: Message-ID: > On 22 Sep 2017, at 08:08, Randy Bush wrote: > > oppressing the proletariat did not work out too randy I?m not sure randiness was affected either way by the oppression of the proletariat. :-) Sorry. Couldn?t resist. From cfriacas at fccn.pt Fri Sep 22 10:15:40 2017 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Fri, 22 Sep 2017 09:15:40 +0100 (WEST) Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: Message-ID: On Fri, 22 Sep 2017, Arash Naderpour wrote: > Hi Carlos, > ? Hi, > This proposal is not aimed at preventing the complete runout. That will happen. This proposal aims to preserve some tiny resources for new entrants in > this community, by trying to extend the time period until the runout occurs. We cannot "measure" its benefits until the runout occurs, and we can then > count how many new entrants did get a tiny portion of (new, never used before) IPv4 address space. > > > The current policy without this change is doing the same, preserving tiny resources (/22) for new entrants.? > You are saying that there are some benefit and we cannot measure them now, but lets do it, am I right? I'm saying there is an obvious benefit: accomodate more new entrants. Because an org is able to have/open multiple LIRs, the real new entrants number is not really easy to calculate :-) > Even if there is a need, it could be 3x/24 or /23.why change it from /22 to /24? > > > Yes, a /23+/24 or a /23 would be a step in the right direction. If, at global level, a /25 or a /26 was acceptable (routing-wise), then that would be > even better.? > > ?I would also like to draw your attention to the last section about "Alignment with other RIRs": LACNIC already has this in place. ARIN has something, > which isn't really exactly the same, but the main goal is very similar. :-) > > ? > > Still unanswered, why /24 not a /23+/24 or a /23? Going to a /24 will potentially accomodate more new entrants than a /23 or a /23+/24, and definitely more than the currently /22. A /25 or a /26 are not feasible as of today. Not sure if it will ever be. > what is the benefit of this "Alignment with other RIRs" to the RIPE community? I don't see any need for that too.? Just to let everyone know we are not "innovating" nothing here. Different communities already took this step towards extending the period where "new entrants" are able to get some IPv4 address space. Regards, Carlos Fria?as > Regards, > > Arash > > > > > > > ? > Arash > > > > On Fri, Sep 22, 2017 at 12:34 AM, Tim Chown wrote: > ? ? ? > On 21 Sep 2017, at 13:33, Aled Morris wrote: > ? ? ? > > ? ? ? > On 21 September 2017 at 12:43, Marco Schmidt wrote: > ? ? ? > The goal of this proposal is to reduce the IPv4 allocations made by the RIPE NCC > ? ? ? > to a /24 (currently a /22) and only to LIRs that have not received an IPv4 allocation > ? ? ? > directly from the RIPE NCC before. > ? ? ? > > ? ? ? > At the current run-rate, do we know what is the expected expiry of the free pool in RIPE's hands? > > ? ? ? There?s http://www.potaroo.net/tools/ipv4/. > > ? ? ? Tim > > > > > > From cfriacas at fccn.pt Fri Sep 22 10:21:20 2017 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Fri, 22 Sep 2017 09:21:20 +0100 (WEST) Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: Message-ID: Hi, <2017-03 co-author hat on> "Access" is not the aim of this policy proposal. Afaik, there was already a proposal which had some common points with what is described below, and it didn't get anywhere then. Regards, Carlos Fria?as On Fri, 22 Sep 2017, noc at kwaoo.net wrote: > Maybe the right path is to find some way to allocate those addresses to > real new entrants only > > Perhaps limitations like only one allocation: > - per LIR > - per legal entity > - per physical person > - per "network", "activity" or whatever, & based on how you should have > your own resources > > Anything that can allow the RIPE to say : "nope, you're obviously trying > to get more stuff from us, you got your part, we deny this allocation" > > This way, the last ressources' purpose will be filled properly, and not > scavenged by greedy guys > > Regards, > > On 22/09/2017 09:04, Carlos Fria?as wrote: >> This proposal is not aimed at preventing the complete runout. That will >> happen. This proposal aims to preserve some tiny resources for new >> entrants in this community, by trying to extend the time period until >> the runout occurs. We cannot "measure" its benefits until the runout >> occurs, and we can then count how many new entrants did get a tiny >> portion of (new, never used before) IPv4 address space. > > -- > Jack > Net/sys admin > > More details about KWAOO can be found at: > https://as24904.kwaoo.net/ > From noc at kwaoo.net Fri Sep 22 10:23:55 2017 From: noc at kwaoo.net (noc at kwaoo.net) Date: Fri, 22 Sep 2017 10:23:55 +0200 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: Message-ID: <118abb74-7fbf-d439-4a7b-8d2c27aff92f@kwaoo.net> Yes I agree with your proposal Regards, On 22/09/2017 10:21, Carlos Fria?as wrote: > > Hi, > > <2017-03 co-author hat on> > > "Access" is not the aim of this policy proposal. > > Afaik, there was already a proposal which had some common points with > what is described below, and it didn't get anywhere then. > > Regards, > Carlos Fria?as > > > > On Fri, 22 Sep 2017, noc at kwaoo.net wrote: > >> Maybe the right path is to find some way to allocate those addresses to >> real new entrants only >> >> Perhaps limitations like only one allocation: >> - per LIR >> - per legal entity >> - per physical person >> - per "network", "activity" or whatever, & based on how you should have >> your own resources >> >> Anything that can allow the RIPE to say : "nope, you're obviously trying >> to get more stuff from us, you got your part, we deny this allocation" >> >> This way, the last ressources' purpose will be filled properly, and not >> scavenged by greedy guys >> >> Regards, >> >> On 22/09/2017 09:04, Carlos Fria?as wrote: >>> This proposal is not aimed at preventing the complete runout. That will >>> happen. This proposal aims to preserve some tiny resources for new >>> entrants in this community, by trying to extend the time period until >>> the runout occurs. We cannot "measure" its benefits until the runout >>> occurs, and we can then count how many new entrants did get a tiny >>> portion of (new, never used before) IPv4 address space. >> >> -- >> Jack >> Net/sys admin >> >> More details about KWAOO can be found at: >> https://as24904.kwaoo.net/ >> -- Jack Kwaoo noc More details about KWAOO can be found at: https://as24904.kwaoo.net/ From frettled at gmail.com Fri Sep 22 10:24:59 2017 From: frettled at gmail.com (Jan Ingvoldstad) Date: Fri, 22 Sep 2017 10:24:59 +0200 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: Message-ID: On Thu, Sep 21, 2017 at 1:43 PM, Marco Schmidt wrote: > Dear colleagues, > > A new RIPE Policy proposal, 2017-03, "Reducing Initial IPv4 Allocation, > aiming to preserve a minimum of IPv4 space", is now available for discussion. > > The goal of this proposal is to reduce the IPv4 allocations made by the RIPE NCC > to a /24 (currently a /22) and only to LIRs that have not received an IPv4 allocation > directly from the RIPE NCC before. > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2017-03/ As laid out, I think this proposal makes sense, and is also presented in due time before it strictly becomes necessary. That's good. An IPv4 allocation of this size (and even less, 32 addresses, but, graaahgh, routing) makes sense to ensure that there can be new entrants for a long time to come, and doesn't seem overly burdensome for new entrants. -- Jan From jim at rfc1035.com Fri Sep 22 10:28:07 2017 From: jim at rfc1035.com (Jim Reid) Date: Fri, 22 Sep 2017 09:28:07 +0100 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: Message-ID: <378746A7-B793-4272-A9F8-8ACC944F25C2@rfc1035.com> > On 22 Sep 2017, at 08:58, noc at kwaoo.net wrote: > > Maybe the right path is to find some way to allocate those addresses to > real new entrants only Come up with a viable definition ?new real entrant?. It?s not as easy as you seem to think it is. > Perhaps limitations like only one allocation: > - per LIR > - per legal entity > - per physical person > - per "network", "activity" or whatever, & based on how you should have > your own resources Now consider how that can be policed. How much is that going to cost? Will the NCC have to buy a DNA sequencer and demand samples from anyone wanting address space? [And what about identical twins?] BTW every LIR is a legal entity and can only get exactly one v4 allocation under the current policy. > Anything that can allow the RIPE to say : "nope, you're obviously trying > to get more stuff from us, you got your part, we deny this allocation? This should already be happening. Though there may well be unscrupulous people who look for and maybe find ways to manipulate the system. No IPv4 allocation policy is perfect or foolproof. The one we?ve got is good enough. It doesn?t need fixing. From arash_mpc at parsun.com Fri Sep 22 10:54:05 2017 From: arash_mpc at parsun.com (Arash Naderpour) Date: Fri, 22 Sep 2017 18:54:05 +1000 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: Message-ID: Hi Carlos, >> > This proposal is not aimed at preventing the complete runout. That >> will happen. This proposal aims to preserve some tiny resources for new >> entrants in >> this community, by trying to extend the time period until the >> runout occurs. We cannot "measure" its benefits until the runout occurs, >> and we can then >> count how many new entrants did get a tiny portion of (new, never >> used before) IPv4 address space. >> >> >> The current policy without this change is doing the same, preserving tiny >> resources (/22) for new entrants. >> You are saying that there are some benefit and we cannot measure them >> now, but lets do it, am I right? >> > > I'm saying there is an obvious benefit: accomodate more new entrants. > > Because an org is able to have/open multiple LIRs, the real new entrants > number is not really easy to calculate :-) > > My understanding from this proposal is that it just change the allocation size but an org is still able to have/open multi LIRs, If this proposal reach consensus, someone still can open four LIRs and get the same amount of IP address as now. The difference (from technical point of view) is that we may have less entry in routing tables with an /22 allocation but with this proposal we will have for sure 4x /24 entry without gaining that much. Regards, Arash > > > Regards, >> >> Arash >> >> >> >> >> >> >> >> Arash >> >> >> >> On Fri, Sep 22, 2017 at 12:34 AM, Tim Chown < >> tjc at ecs.soton.ac.uk> wrote: >> > On 21 Sep 2017, at 13:33, Aled Morris < >> aled.w.morris at googlemail.com> wrote: >> > >> > On 21 September 2017 at 12:43, Marco Schmidt < >> mschmidt at ripe.net> wrote: >> > The goal of this proposal is to reduce the IPv4 >> allocations made by the RIPE NCC >> > to a /24 (currently a /22) and only to LIRs that have >> not received an IPv4 allocation >> > directly from the RIPE NCC before. >> > >> > At the current run-rate, do we know what is the >> expected expiry of the free pool in RIPE's hands? >> >> There?s http://www.potaroo.net/tools/ipv4/. >> >> Tim >> >> >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From Flavio.Palumbo at windtre.it Fri Sep 22 10:17:24 2017 From: Flavio.Palumbo at windtre.it (Palumbo Flavio) Date: Fri, 22 Sep 2017 08:17:24 +0000 Subject: [address-policy-wg] R: 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <397fd725-0403-dca7-539e-1550faa5e0e3@danysek.cz> References: <397fd725-0403-dca7-539e-1550faa5e0e3@danysek.cz> Message-ID: I don't see TOO any problem in reduction of initial (minimal) IPv4 allocation. So i support this idea TOO . -----Messaggio originale----- Da: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] Per conto di Daniel Suchy Inviato: venerd? 22 settembre 2017 10:09 A: address-policy-wg at ripe.net Oggetto: Re: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) Hello, /24 is de-facto standard accepted in routing tables these days and also /24 was used in large scale during PI assignments - so I don't see any problem in reduction of initial (minimal) IPv4 allocation. So i support this idea. But I would like to keep option for asking more than /24 (up to /22 maximum, as was decided in the past) LIRs eligible for allocation, if LIR properly documents his request. From my own practice there're some LIR, where /24 is sufficient and they just become LIRs because there's no other real option to get independent addresses (old "PI") and with /22 we're just wasting limited resource. But there're also LIRs, where /22 will actively used. I don't see any problems in terms of RFC 2050 mentioned here and memory contraints, providers had to upgrade their routers in meantime anyway (at least due to IPv6 adoption). Fragmentation up to /24 is long-term reality and we had to deal with it anyway. With regards, Daniel On 09/21/2017 01:43 PM, Marco Schmidt wrote: > Dear colleagues, > > A new RIPE Policy proposal, 2017-03, "Reducing Initial IPv4 > Allocation, aiming to preserve a minimum of IPv4 space", is now available for discussion. > > The goal of this proposal is to reduce the IPv4 allocations made by > the RIPE NCC to a /24 (currently a /22) and only to LIRs that have not > received an IPv4 allocation directly from the RIPE NCC before. > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2017-03/ > > As per the RIPE Policy Development Process (PDP), the purpose of this > four-week Discussion Phase is to discuss the proposal and provide feedback to the proposer. > > At the end of the Discussion Phase, the proposer, with the agreement > of the RIPE Working Group Chairs, decides how to proceed with the proposal. > > We encourage you to review this proposal and send your comments to > before 20 October 2017. > > Kind regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > Check Point Le informazioni contenute in questo messaggio di posta elettronica e in ogni eventuale documento allegato sono riservate, potrebbero essere coperte dal segreto professionale e possono essere utilizzate esclusivamente dal destinatario sopra indicato. Ogni divulgazione o copia di questo messaggio o dei suoi eventuali allegati non autorizzata, cosi' come ogni uso o divulgazione delle informazioni negli stessi contenute, sono da considerarsi come vietate e potrebbero costituire violazione delle normative ivi applicabili. Se ricevete questo messaggio per errore Vi preghiamo di volerci avvertire immediatamente tramite posta elettronica o telefonicamente e di cancellare il presente messaggio e ogni documento ad esso allegato dal Vostro sistema. Vi informiamo che svolgiamo ogni attivita' finalizzata a proteggere la nostra rete da virus e non ci assumiamo alcuna responsabilita' in ordine a possibili virus che possano essere trasferiti con la presente mail. Grazie. ***************** The information contained in this e-mail and in any file transmitted with it is confidential and may be privileged for the sole use of the designated addressee. Any unauthorized dissemination or copying of this e-mail or its attachments, and any use or disclosure of any information contained in them, is strictly prohibited and may be illegal. If you are not the designated addressee, please notify the sender immediately by e-mail or by telephone and delete this e-mail and any file transmitted with it from your system. We make every effort to keep our network free from viruses and take no responsibility for any computer virus which might be transferred by way of this e-mail. Thank you. From raymond.jetten at elisa.fi Fri Sep 22 11:40:21 2017 From: raymond.jetten at elisa.fi (Jetten Raymond) Date: Fri, 22 Sep 2017 09:40:21 +0000 Subject: [address-policy-wg] R: 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: <397fd725-0403-dca7-539e-1550faa5e0e3@danysek.cz> Message-ID: Dear AP-WG, I Oppose this 2017-03 proposal, IPv6 has been around for decades, and "we" have failed to implement it in time. I see no point in rewarding laziness and yet trying to again give more time to seriously start to implement v6. The more time we are given, the more time it will take, that?s how we have done it in the past, and I don?t see the laziness go if not forced to. Warnings were ignored, we (v6 advocates) were laughed at, "again it will end", " you?ve told us that many years". Even if we only hand out a /28, we still have the basic problem, and it won't go away v4 WILL run out. Don?t make the suffering any longer. Rgds, Ray -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Palumbo Flavio Sent: 22. syyskuuta 2017 11:17 To: Daniel Suchy ; address-policy-wg at ripe.net Subject: [address-policy-wg] R: 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) I don't see TOO any problem in reduction of initial (minimal) IPv4 allocation. So i support this idea TOO . -----Messaggio originale----- Da: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] Per conto di Daniel Suchy Inviato: venerd? 22 settembre 2017 10:09 A: address-policy-wg at ripe.net Oggetto: Re: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) Hello, /24 is de-facto standard accepted in routing tables these days and also /24 was used in large scale during PI assignments - so I don't see any problem in reduction of initial (minimal) IPv4 allocation. So i support this idea. But I would like to keep option for asking more than /24 (up to /22 maximum, as was decided in the past) LIRs eligible for allocation, if LIR properly documents his request. From my own practice there're some LIR, where /24 is sufficient and they just become LIRs because there's no other real option to get independent addresses (old "PI") and with /22 we're just wasting limited resource. But there're also LIRs, where /22 will actively used. I don't see any problems in terms of RFC 2050 mentioned here and memory contraints, providers had to upgrade their routers in meantime anyway (at least due to IPv6 adoption). Fragmentation up to /24 is long-term reality and we had to deal with it anyway. With regards, Daniel On 09/21/2017 01:43 PM, Marco Schmidt wrote: > Dear colleagues, > > A new RIPE Policy proposal, 2017-03, "Reducing Initial IPv4 > Allocation, aiming to preserve a minimum of IPv4 space", is now available for discussion. > > The goal of this proposal is to reduce the IPv4 allocations made by > the RIPE NCC to a /24 (currently a /22) and only to LIRs that have not > received an IPv4 allocation directly from the RIPE NCC before. > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2017-03/ > > As per the RIPE Policy Development Process (PDP), the purpose of this > four-week Discussion Phase is to discuss the proposal and provide feedback to the proposer. > > At the end of the Discussion Phase, the proposer, with the agreement > of the RIPE Working Group Chairs, decides how to proceed with the proposal. > > We encourage you to review this proposal and send your comments to > before 20 October 2017. > > Kind regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > Check Point Le informazioni contenute in questo messaggio di posta elettronica e in ogni eventuale documento allegato sono riservate, potrebbero essere coperte dal segreto professionale e possono essere utilizzate esclusivamente dal destinatario sopra indicato. Ogni divulgazione o copia di questo messaggio o dei suoi eventuali allegati non autorizzata, cosi' come ogni uso o divulgazione delle informazioni negli stessi contenute, sono da considerarsi come vietate e potrebbero costituire violazione delle normative ivi applicabili. Se ricevete questo messaggio per errore Vi preghiamo di volerci avvertire immediatamente tramite posta elettronica o telefonicamente e di cancellare il presente messaggio e ogni documento ad esso allegato dal Vostro sistema. Vi informiamo che svolgiamo ogni attivita' finalizzata a proteggere la nostra rete da virus e non ci assumiamo alcuna responsabilita' in ordine a possibili virus che possano essere trasferiti con la presente mail. Grazie. ***************** The information contained in this e-mail and in any file transmitted with it is confidential and may be privileged for the sole use of the designated addressee. Any unauthorized dissemination or copying of this e-mail or its attachments, and any use or disclosure of any information contained in them, is strictly prohibited and may be illegal. If you are not the designated addressee, please notify the sender immediately by e-mail or by telephone and delete this e-mail and any file transmitted with it from your system. We make every effort to keep our network free from viruses and take no responsibility for any computer virus which might be transferred by way of this e-mail. Thank you. From h.lu at anytimechinese.com Fri Sep 22 11:41:55 2017 From: h.lu at anytimechinese.com (Lu Heng) Date: Fri, 22 Sep 2017 09:41:55 +0000 Subject: [address-policy-wg] R: 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: <397fd725-0403-dca7-539e-1550faa5e0e3@danysek.cz> Message-ID: On Fri, Sep 22, 2017 at 17:40 Jetten Raymond wrote: > Dear AP-WG, > > I Oppose this 2017-03 proposal, > > IPv6 has been around for decades, and "we" have failed to implement it in > time. I see no point in rewarding laziness and yet trying to again give > more time to seriously start to implement v6. The more time we are given, > the more time it will take, that?s how we have done it in the past, and I > don?t see the laziness go if not forced to. Warnings were ignored, we (v6 > advocates) were laughed at, "again it will end", " you?ve told us that many > years". Even if we only hand out a /28, we still have the basic problem, > and it won't go away v4 WILL run out. Don?t make the suffering any longer. > > Rgds, > > Ray > +1 > > -----Original Message----- > From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On > Behalf Of Palumbo Flavio > Sent: 22. syyskuuta 2017 11:17 > To: Daniel Suchy ; address-policy-wg at ripe.net > Subject: [address-policy-wg] R: 2017-03 New Policy Proposal (Reducing > Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) > > I don't see TOO any problem in reduction of initial (minimal) IPv4 > allocation. So i support this idea TOO . > > -----Messaggio originale----- > Da: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] Per > conto di Daniel Suchy > Inviato: venerd? 22 settembre 2017 10:09 > A: address-policy-wg at ripe.net > Oggetto: Re: [address-policy-wg] 2017-03 New Policy Proposal (Reducing > Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) > > Hello, > /24 is de-facto standard accepted in routing tables these days and also > /24 was used in large scale during PI assignments - so I don't see any > problem in reduction of initial (minimal) IPv4 allocation. So i support > this idea. > > But I would like to keep option for asking more than /24 (up to /22 > maximum, as was decided in the past) LIRs eligible for allocation, if LIR > properly documents his request. > > From my own practice there're some LIR, where /24 is sufficient and they > just become LIRs because there's no other real option to get independent > addresses (old "PI") and with /22 we're just wasting limited resource. > But there're also LIRs, where /22 will actively used. > > I don't see any problems in terms of RFC 2050 mentioned here and memory > contraints, providers had to upgrade their routers in meantime anyway (at > least due to IPv6 adoption). Fragmentation up to /24 is long-term reality > and we had to deal with it anyway. > > With regards, > Daniel > > > On 09/21/2017 01:43 PM, Marco Schmidt wrote: > > Dear colleagues, > > > > A new RIPE Policy proposal, 2017-03, "Reducing Initial IPv4 > > Allocation, aiming to preserve a minimum of IPv4 space", is now > available for discussion. > > > > The goal of this proposal is to reduce the IPv4 allocations made by > > the RIPE NCC to a /24 (currently a /22) and only to LIRs that have not > > received an IPv4 allocation directly from the RIPE NCC before. > > > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2017-03/ > > > > As per the RIPE Policy Development Process (PDP), the purpose of this > > four-week Discussion Phase is to discuss the proposal and provide > feedback to the proposer. > > > > At the end of the Discussion Phase, the proposer, with the agreement > > of the RIPE Working Group Chairs, decides how to proceed with the > proposal. > > > > We encourage you to review this proposal and send your comments to > > before 20 October 2017. > > > > Kind regards, > > > > Marco Schmidt > > Policy Development Officer > > RIPE NCC > > > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > > > > > Check Point > Le informazioni contenute in questo messaggio di posta elettronica e in > ogni > eventuale documento allegato sono riservate, potrebbero essere coperte dal > segreto professionale e possono essere utilizzate esclusivamente dal > destinatario sopra indicato. Ogni divulgazione o copia di questo messaggio > o > dei suoi eventuali allegati non autorizzata, cosi' come ogni uso o > divulgazione delle informazioni negli stessi contenute, sono da > considerarsi > come vietate e potrebbero costituire violazione delle normative ivi > applicabili. Se ricevete questo messaggio per errore Vi preghiamo di > volerci avvertire immediatamente tramite posta elettronica o > telefonicamente > e di cancellare il presente messaggio e ogni documento ad esso allegato dal > Vostro sistema. Vi informiamo che svolgiamo ogni attivita' finalizzata a > proteggere la nostra rete da virus e non ci assumiamo alcuna > responsabilita' > in ordine a possibili virus che possano essere trasferiti con la presente > mail. > Grazie. > > ***************** > > The information contained in this e-mail and in any file transmitted with > it > is confidential and may be privileged for the sole use of the designated > addressee. Any unauthorized dissemination or copying of this e-mail or its > attachments, and any use or disclosure of any information contained in > them, > is strictly prohibited and may be illegal. If you are not the designated > addressee, please notify the sender immediately by e-mail or by telephone > and delete this e-mail and any file transmitted with it from your system. > We make every effort to keep our network free from viruses and take no > responsibility for any computer virus which might be transferred by way of > this > e-mail. > Thank you. > -- -- Kind regards. Lu -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjc at ecs.soton.ac.uk Fri Sep 22 12:06:27 2017 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Fri, 22 Sep 2017 11:06:27 +0100 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: <59C3C608.8050009@foobar.org> Message-ID: > On 22 Sep 2017, at 08:18, Randy Bush wrote: > > > > when v4 runout forces folk to put /28s in frnt of nats, the folk with > shiny shoes will have a little chat with senior leadership, and they'll > cough up the bucks to hold the routes. history repeats. Doesn?t the ARIN policy potentially mean applicants will get a /28? Are those being filtered, or aggregated locally to avoid that? See https://www.arin.net/policy/nrpm.html#four10 Tim From tjc at ecs.soton.ac.uk Fri Sep 22 12:04:02 2017 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Fri, 22 Sep 2017 11:04:02 +0100 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: <861BFD37-7987-43B8-A459-4478E154AA21@ecs.soton.ac.uk> Message-ID: > On 22 Sep 2017, at 05:50, Mikael Abrahamsson wrote: > > On Thu, 21 Sep 2017, Tim Chown wrote: > >>> At the current run-rate, do we know what is the expected expiry of the free pool in RIPE's hands? >> >> There?s http://www.potaroo.net/tools/ipv4/. > > There is also: > > https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustion/ipv4-available-pool-graph > > Looks to me that there is still IPv4 space being returned, the run-rate on 185/8 is constant, we have approximately 4-5 years to go? > > To me it looks like things are going according to plan, and I don't see any need to change anything. I?d agree with that. The proposal does no analysis of the ?run rate? of consumption, or other the impact of other RIR policies. I?d like to see that presented. Looking at https://www.ripe.net/participate/policies/proposals/2017-03/, it seems that LACNIC have moved from a /22 to a /24 policy last month (so hard to measure impact yet), and ARIN are on a last /10 policy which sees applicants get a /28 to a /24, so presumably those /28?s are routed at some level; that?s been in place for some time, how is it working out? What about APNIC and AFRINIC? The current run-out projection is 2021/22, five years away. Consider where IPv6 deployment was 5 years ago. Since then we?ve gone from ~0% deployment worldwide to ~20%, and seen a wide range of ISPs and content providers deploy, and importantly the bigger CDNs now provide dual-stack by default out-of the box. Consider where we?ll be in 5 years from now. Tim PS. Seeing ?more members? as a benefit is a strange advantage to add in the proposal, given these are implicitly people gaming the system? From danny at danysek.cz Fri Sep 22 12:11:45 2017 From: danny at danysek.cz (Daniel Suchy) Date: Fri, 22 Sep 2017 12:11:45 +0200 Subject: [address-policy-wg] R: 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: <397fd725-0403-dca7-539e-1550faa5e0e3@danysek.cz> Message-ID: <030b209d-f3c3-54d0-ebc2-0e3884c65bda@danysek.cz> On 09/22/2017 11:40 AM, Jetten Raymond wrote: > IPv6 has been around for decades, and "we" have failed to implement it in time. I see no point in rewarding laziness and yet trying to again give more time to seriously start to implement v6. The more time we are given, the more time it will take, that?s how we have done it in the past, and I don?t see the laziness go if not forced to. Warnings were ignored, we (v6 advocates) were laughed at, "again it will end", " you?ve told us that many years". Even if we only hand out a /28, we still have the basic problem, and it won't go away v4 WILL run out. Don?t make the suffering any longer. What you expect you can solve by "fast" depletion? Nothing, in my eyes. There're other mechanisms used to overcome lack of IPv4 in access networks (since RFC 1631 was introduced), and yes - there're "lazy" providers without IPv6 within their networks. And they can (and will) survive for many years without IPv6 implemented - as there isn't any major IPv6-only service. >From content-provider perspective, you cannot start new services without IPv4 and simply cut some customers behind IPv4 NATs from your business. We have to deal with reality - IPv6 adoption is slower than we expected. Even standardisation of IPv6 was quite slow in some details - we had to wait 18 years for RFC 8200... - Daniel From tjc at ecs.soton.ac.uk Fri Sep 22 12:22:16 2017 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Fri, 22 Sep 2017 11:22:16 +0100 Subject: [address-policy-wg] R: 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <030b209d-f3c3-54d0-ebc2-0e3884c65bda@danysek.cz> References: <397fd725-0403-dca7-539e-1550faa5e0e3@danysek.cz> <030b209d-f3c3-54d0-ebc2-0e3884c65bda@danysek.cz> <7B4990A9-34DC-4F37-86A0-12D3F288F86C@ecs.soton.ac.uk> Message-ID: > On 22 Sep 2017, at 11:11, Daniel Suchy wrote: > > > > Even standardisation of IPv6 was quite slow in some details - we had to > wait 18 years for RFC 8200... But that rally wasn?t a major change in any way from RFC2460, modulo the few errata that had already been applied over the years. The point of RFC 8200 was to move the core IPv6 spec to full Internet Standard status, which actually very few RFCs have. Tim From raymond.jetten at elisa.fi Fri Sep 22 12:27:36 2017 From: raymond.jetten at elisa.fi (Jetten Raymond) Date: Fri, 22 Sep 2017 10:27:36 +0000 Subject: [address-policy-wg] R: 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <030b209d-f3c3-54d0-ebc2-0e3884c65bda@danysek.cz> References: <397fd725-0403-dca7-539e-1550faa5e0e3@danysek.cz> <030b209d-f3c3-54d0-ebc2-0e3884c65bda@danysek.cz> Message-ID: --snip--. We have to deal with reality - IPv6 adoption is slower than we expected. Even standardisation of IPv6 was quite slow in some details - we had to wait 18 years for RFC 8200... -True, there was probably not enough pressure, but giving yet more time will not speed up the integration either. -Ray - Daniel From anna.wilson at heanet.ie Fri Sep 22 12:31:38 2017 From: anna.wilson at heanet.ie (Anna Wilson) Date: Fri, 22 Sep 2017 11:31:38 +0100 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: <397fd725-0403-dca7-539e-1550faa5e0e3@danysek.cz> Message-ID: Hello Ray, > On 22 Sep 2017, at 10:40, Jetten Raymond wrote: > I Oppose this 2017-03 proposal, > > IPv6 has been around for decades, and "we" have failed to implement it in time. I see no point in rewarding laziness and yet trying to again give more time to seriously start to implement v6. The more time we are given, the more time it will take, that?s how we have done it in the past, and I don?t see the laziness go if not forced to. Warnings were ignored, we (v6 advocates) were laughed at, "again it will end", " you?ve told us that many years". Even if we only hand out a /28, we still have the basic problem, and it won't go away v4 WILL run out. Don?t make the suffering any longer. I'm a co-author of the proposal... and I agree with you, in as much that postponing efforts to deploy v6 is rewarding the wrong thing. But I don't recall that being the goal of the original last /8 proposal at all. Our observations are: - in order for new entrants to deploy v6 at all, they currently need a little bit of v4 - this fact is probably not going to change between now and the currently-expected runout of the last /8 So, just like the original last /8 proposal, I believe that this is a pro-v6 proposal. All that's changed between the original last /8 proposal and now is that we now have a picture of the run-rate of the last /8. So this proposal is to give more new entrants the chance to join the v6 internet - with the bit of v4 they need to do that - instead of allowing the rest of us to externalise the cost of v4 runout even further. Best regards, Anna -- Anna Wilson Service Desk Manager HEAnet CLG, Ireland?s National Education and Research Network 1st Floor, 5 George?s Dock, IFSC, Dublin D01 X8N7, Ireland +353 (0)1 6609040 anna.wilson at heanet.ie www.heanet.ie Registered in Ireland, No. 275301. CRA No. 20036270 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom.hill at bytemark.co.uk Fri Sep 22 12:54:19 2017 From: tom.hill at bytemark.co.uk (Tom Hill) Date: Fri, 22 Sep 2017 11:54:19 +0100 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: <59C3C608.8050009@foobar.org> <6ccee8bc-a770-8457-9a44-851ac73ad91e@bytemark.co.uk> Message-ID: On 21/09/17 20:22, Randy Bush wrote: > once it was /19. welcome to life. I think the stakes are a little higher these days. -- Tom Hill Network Manager Bytemark Hosting http://www.bytemark.co.uk/ tel. +44 1904 890 890 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From raymond.jetten at elisa.fi Fri Sep 22 13:04:17 2017 From: raymond.jetten at elisa.fi (Jetten Raymond) Date: Fri, 22 Sep 2017 11:04:17 +0000 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: <397fd725-0403-dca7-539e-1550faa5e0e3@danysek.cz> Message-ID: <99c23a41034545ebb5eef1c212ce128b@elisa.fi> Hi Anna, I saw some calculations that with the current policy it would be 4-5 years, to run completely out, last /8 and returned space. Now I don?t know if these calculations are correct, but even if they are, or not, then I would like to know how long it should last ? 10 years, 20 , 50? I can see and understand your points, the original /8 proposal was not meant to delay v6, fully agree, but by spreading it now it will be expected to be spread out again in say 2-4 years (?) . I seriously think that the more time we get, or give the illusion that we can then rearrange it again, the more time people will ignore the fact that it will run out, regardless if we change the policy or not. Therefore I still think the current policy is sufficient. Rgds, Ray From: Anna Wilson [mailto:anna.wilson at heanet.ie] Sent: 22. syyskuuta 2017 13:32 To: Jetten Raymond Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) Hello Ray, On 22 Sep 2017, at 10:40, Jetten Raymond > wrote: I Oppose this 2017-03 proposal, IPv6 has been around for decades, and "we" have failed to implement it in time. I see no point in rewarding laziness and yet trying to again give more time to seriously start to implement v6. The more time we are given, the more time it will take, that?s how we have done it in the past, and I don?t see the laziness go if not forced to. Warnings were ignored, we (v6 advocates) were laughed at, "again it will end", " you?ve told us that many years". Even if we only hand out a /28, we still have the basic problem, and it won't go away v4 WILL run out. Don?t make the suffering any longer. I'm a co-author of the proposal... and I agree with you, in as much that postponing efforts to deploy v6 is rewarding the wrong thing. But I don't recall that being the goal of the original last /8 proposal at all. Our observations are: - in order for new entrants to deploy v6 at all, they currently need a little bit of v4 - this fact is probably not going to change between now and the currently-expected runout of the last /8 So, just like the original last /8 proposal, I believe that this is a pro-v6 proposal. All that's changed between the original last /8 proposal and now is that we now have a picture of the run-rate of the last /8. So this proposal is to give more new entrants the chance to join the v6 internet - with the bit of v4 they need to do that - instead of allowing the rest of us to externalise the cost of v4 runout even further. Best regards, Anna -- Anna Wilson Service Desk Manager HEAnet CLG, Ireland?s National Education and Research Network 1st Floor, 5 George?s Dock, IFSC, Dublin D01 X8N7, Ireland +353 (0)1 6609040 anna.wilson at heanet.ie www.heanet.ie Registered in Ireland, No. 275301. CRA No. 20036270 -------------- next part -------------- An HTML attachment was scrubbed... URL: From noc at kwaoo.net Fri Sep 22 13:11:14 2017 From: noc at kwaoo.net (noc at kwaoo.net) Date: Fri, 22 Sep 2017 13:11:14 +0200 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <99c23a41034545ebb5eef1c212ce128b@elisa.fi> References: <397fd725-0403-dca7-539e-1550faa5e0e3@danysek.cz> <99c23a41034545ebb5eef1c212ce128b@elisa.fi> Message-ID: <5ef218d5-7ece-e889-cf78-15f6b1be3d6b@kwaoo.net> This proposal will increase per-IP price Thus, it will promote alternatives (IPv6 !) Today at $work, there is nothing planned to get rid of IPv4. Why should we ? Buying some is less expensive than working on hybrid solution. On 22/09/2017 13:04, Jetten Raymond wrote: > I seriously think that the more time we get, or give the illusion that we can then rearrange it again, the more time people will ignore the fact that it will run out, regardless if we change the policy or not. -- Jack Kwaoo noc More details about KWAOO can be found at: https://as24904.kwaoo.net/ From jim at rfc1035.com Fri Sep 22 13:18:39 2017 From: jim at rfc1035.com (Jim Reid) Date: Fri, 22 Sep 2017 12:18:39 +0100 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <5ef218d5-7ece-e889-cf78-15f6b1be3d6b@kwaoo.net> References: <397fd725-0403-dca7-539e-1550faa5e0e3@danysek.cz> <99c23a41034545ebb5eef1c212ce128b@elisa.fi> <5ef218d5-7ece-e889-cf78-15f6b1be3d6b@kwaoo.net> Message-ID: > On 22 Sep 2017, at 12:11, noc at kwaoo.net wrote: > > Today at $work, there is nothing planned to get rid of IPv4. Why should > we ? Buying some is less expensive than working on hybrid solution. So what? How could a change in the current v4 address policy possibly change that behaviour? If your company can?t/won?t prepare for the inevitable, you only have yourselves to blame. From rhe at nosc.ja.net Fri Sep 22 13:48:06 2017 From: rhe at nosc.ja.net (Rob Evans) Date: Fri, 22 Sep 2017 12:48:06 +0100 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: Message-ID: <87742FA9-32B9-42A1-97D0-46B98A21D2A1@nosc.ja.net> Hi all, I think it?s worth remembering that there is a time lag between policies being implemented and them having an effect on the market. Forgive me if I go into a bit of speculation, but where would we be if RIRs hadn?t implemented a ?last /8? policy? The RIPE NCC?s coffers would almost certainly be dry and the only realistic means of obtaining IPv4 addresses would be through the open market. The price would be higher than it is now, but would IPv6 deployment be any higher? Existing companies would be in the same situation they are in now, with no more incentive to deploy IPv6 (where is that killer app?), and some small companies would not have been able to get off the ground. What this policy is trying to do is get around that fact that a lot of the industry (probably not the ones on this list) still have their head in the sand as far as IPv4 depletion goes. It?s ?I?m alright Jack?, and it is taking longer than anyone expected to get the message across. I?m not convinced running dry is going to change that. However, the message is getting across, slowly but surely, and IPv6 adoption is growing not just among the sort of people that participate in these discussions and network operator fora, but in the enterprise networks and even hotel and cafe wireless networks. We have to believe we will get there in the end, but we need to make sure we have the resources to get there, it?s too late to change policies when we are already out of addresses. If we ran out of IPv4 resources today, will it change the IPv6 deployment plans of those that already have IPv4? What will be different for them compared to the situation where we keep some dregs of IPv4 for new entrants to the market? The fact that *they* can?t get any more addresses from the NCC? That?s no different to the situation now. I would dearly love to see the end of IPv4 policies, and perhaps I?d prefer this policy if it had a sliding scale that changed the initial allocation size based on what was left in the NCC?s resource pool, but that might be too arbitrary ? then again /22 and /24 are also, to some extent, arbitrary. Dropping down to the minimum currently routed size makes quite a bit of sense ? these are the last bits of IPv4, here is your slice, it?s the same for all newcomers. We are in the end-game. Cheers, Rob From cfriacas at fccn.pt Fri Sep 22 13:52:14 2017 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Fri, 22 Sep 2017 12:52:14 +0100 (WEST) Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: Message-ID: On Fri, 22 Sep 2017, Arash Naderpour wrote: > Hi Carlos, > Hi, > ? ? ? This proposal is not aimed at preventing the complete runout. That will happen. This proposal aims to preserve some tiny resources for > new entrants in > ? ? ? this community, by trying to extend the time period until the runout occurs. We cannot "measure" its benefits until the runout occurs, > and we can then > ? ? ? count how many new entrants did get a tiny portion of (new, never used before) IPv4 address space. > > > The current policy without this change is doing the same, preserving tiny resources (/22) for new entrants.? > You are saying that there are some benefit and we cannot measure them now, but lets do it, am I right? > > > I'm saying there is an obvious benefit: accomodate more new entrants. > > Because an org is able to have/open multiple LIRs, the real new entrants number is not really easy to calculate :-) > > > My understanding from this proposal is that it just change the allocation size but an org is still able to have/open multi LIRs, Yes, the ability of having multiple LIRs is out of scope, regarding this proposal. According to the PDP, afaik, anyone can submit a new proposal about that. > If this proposal reach consensus, someone still can open four LIRs and > get the same amount of IP address as now. That's my understanding too. or five, or six, or seven, and so on... > The difference (from technical > point of view) is that we may have less entry in routing tables with an > /22 allocation This is not really true, because routing-wise a /22 allocation can originate 4x /24 announcements anyway. > but with this proposal we will have for sure 4x /24 entry > without gaining that much. Or not, if the same org manages to open two (or four) new LIRs and the two (or four) /24s are aggregatable. But the main goal here is not to preserve aggregability nor preventing the dfz from growing. Something that i expect from this proposal is buying out a bit more of time for those organizations which are not a LIR today. Regards, Carlos Fria?as > > Regards, > > Arash > > ? > > > > > > Regards, > > Arash > > > > > > > ? > ? ? ? ? ? ? Arash > > > > ? ? ? ? ? ? On Fri, Sep 22, 2017 at 12:34 AM, Tim Chown wrote: > ? ? ? ? ? ? ? ? ? > On 21 Sep 2017, at 13:33, Aled Morris wrote: > ? ? ? ? ? ? ? ? ? > > ? ? ? ? ? ? ? ? ? > On 21 September 2017 at 12:43, Marco Schmidt wrote: > ? ? ? ? ? ? ? ? ? > The goal of this proposal is to reduce the IPv4 allocations made by the RIPE NCC > ? ? ? ? ? ? ? ? ? > to a /24 (currently a /22) and only to LIRs that have not received an IPv4 allocation > ? ? ? ? ? ? ? ? ? > directly from the RIPE NCC before. > ? ? ? ? ? ? ? ? ? > > ? ? ? ? ? ? ? ? ? > At the current run-rate, do we know what is the expected expiry of the free pool in RIPE's hands? > > ? ? ? ? ? ? ? ? ? There?s http://www.potaroo.net/tools/ipv4/. > > ? ? ? ? ? ? ? ? ? Tim > > > > > > > > From raymond.jetten at elisa.fi Fri Sep 22 13:59:34 2017 From: raymond.jetten at elisa.fi (Jetten Raymond) Date: Fri, 22 Sep 2017 11:59:34 +0000 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <87742FA9-32B9-42A1-97D0-46B98A21D2A1@nosc.ja.net> References: <87742FA9-32B9-42A1-97D0-46B98A21D2A1@nosc.ja.net> Message-ID: <7fb06a1f655c48459e68b4212bd9f09c@elisa.fi> Hi Rob, The killer app : Most companies want to grow, especially those that serve shareholders, so imho expandability is the "app" . ? these are the last bits of IPv4, here is your slice, it?s the same for all newcomers. We are in the end-game. Indeed, we have been there for a while, making it longer will not change behavior as you concluded earlier in your message. Rgds, Ray -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Rob Evans Sent: 22. syyskuuta 2017 14:48 To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) Hi all, I think it?s worth remembering that there is a time lag between policies being implemented and them having an effect on the market. Forgive me if I go into a bit of speculation, but where would we be if RIRs hadn?t implemented a ?last /8? policy? The RIPE NCC?s coffers would almost certainly be dry and the only realistic means of obtaining IPv4 addresses would be through the open market. The price would be higher than it is now, but would IPv6 deployment be any higher? Existing companies would be in the same situation they are in now, with no more incentive to deploy IPv6 (where is that killer app?), and some small companies would not have been able to get off the ground. What this policy is trying to do is get around that fact that a lot of the industry (probably not the ones on this list) still have their head in the sand as far as IPv4 depletion goes. It?s ?I?m alright Jack?, and it is taking longer than anyone expected to get the message across. I?m not convinced running dry is going to change that. However, the message is getting across, slowly but surely, and IPv6 adoption is growing not just among the sort of people that participate in these discussions and network operator fora, but in the enterprise networks and even hotel and cafe wireless networks. We have to believe we will get there in the end, but we need to make sure we have the resources to get there, it?s too late to change policies when we are already out of addresses. If we ran out of IPv4 resources today, will it change the IPv6 deployment plans of those that already have IPv4? What will be different for them compared to the situation where we keep some dregs of IPv4 for new entrants to the market? The fact that *they* can?t get any more addresses from the NCC? That?s no different to the situation now. I would dearly love to see the end of IPv4 policies, and perhaps I?d prefer this policy if it had a sliding scale that changed the initial allocation size based on what was left in the NCC?s resource pool, but that might be too arbitrary ? then again /22 and /24 are also, to some extent, arbitrary. Dropping down to the minimum currently routed size makes quite a bit of sense ? these are the last bits of IPv4, here is your slice, it?s the same for all newcomers. We are in the end-game. Cheers, Rob From hunekm at gmail.com Fri Sep 22 14:24:09 2017 From: hunekm at gmail.com (Martin =?utf-8?B?SHVuxJtr?=) Date: Fri, 22 Sep 2017 14:24:09 +0200 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) Message-ID: <94134759.9xlNH3TRUR@rumburak> Hello, I don't think that there is anyone whom would not be able to justify /22. So I think that there should not be any need for justification. Simply because it would be one more meaningless paper, nothing more. Secondly, for me having more specific routes than /24 doesn't seems seem as the right solution for IPv4. More specific routes means more routes in table, so more resources spent on legacy protocol. As for the core of the proposal - droping maximal allocation size from /22 to /24: I don't think that keeping PA pool longer than needed is good for future of an Internet. Maybe it would be better to transfer more space in PI IX pool, drop the restrictions on that pool which prevents to use it for CGN and let the PA space run flat. Long story short, I'm aginst the 2017-03 policy as it is written right now. Best Regards, Martin Hunek Dne p?tek 22. z??? 2017 10:09:28 CEST, Daniel Suchy napsal(a): > Hello, > /24 is de-facto standard accepted in routing tables these days and also > /24 was used in large scale during PI assignments - so I don't see any > problem in reduction of initial (minimal) IPv4 allocation. So i support > this idea. > > But I would like to keep option for asking more than /24 (up to /22 > maximum, as was decided in the past) LIRs eligible for allocation, if > LIR properly documents his request. > > From my own practice there're some LIR, where /24 is sufficient and they > just become LIRs because there's no other real option to get independent > addresses (old "PI") and with /22 we're just wasting limited resource. > But there're also LIRs, where /22 will actively used. > > I don't see any problems in terms of RFC 2050 mentioned here and memory > contraints, providers had to upgrade their routers in meantime anyway > (at least due to IPv6 adoption). Fragmentation up to /24 is long-term > reality and we had to deal with it anyway. > > With regards, > Daniel > > On 09/21/2017 01:43 PM, Marco Schmidt wrote: > > Dear colleagues, > > > > A new RIPE Policy proposal, 2017-03, "Reducing Initial IPv4 Allocation, > > aiming to preserve a minimum of IPv4 space", is now available for > > discussion. > > > > The goal of this proposal is to reduce the IPv4 allocations made by the > > RIPE NCC to a /24 (currently a /22) and only to LIRs that have not > > received an IPv4 allocation directly from the RIPE NCC before. > > > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2017-03/ > > > > As per the RIPE Policy Development Process (PDP), the purpose of this > > four-week Discussion Phase is to discuss the proposal and provide feedback > > to the proposer. > > > > At the end of the Discussion Phase, the proposer, with the agreement of > > the RIPE Working Group Chairs, decides how to proceed with the proposal. > > > > We encourage you to review this proposal and send your comments to > > before 20 October 2017. > > > > Kind regards, > > > > Marco Schmidt > > Policy Development Officer > > RIPE NCC > > > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From jack at k-net.pro Fri Sep 22 13:11:09 2017 From: jack at k-net.pro (jack at k-net.pro) Date: Fri, 22 Sep 2017 13:11:09 +0200 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <99c23a41034545ebb5eef1c212ce128b@elisa.fi> References: <397fd725-0403-dca7-539e-1550faa5e0e3@danysek.cz> <99c23a41034545ebb5eef1c212ce128b@elisa.fi> Message-ID: This proposal will increase per-IP price Thus, it will promote alternatives (IPv6 !) Today at $work, there is nothing planned to get rid of IPv4. Why should we ? Buying some is less expensive than working on hybrid solution. On 22/09/2017 13:04, Jetten Raymond wrote: > I seriously think that the more time we get, or give the illusion that we can then rearrange it again, the more time people will ignore the fact that it will run out, regardless if we change the policy or not. -- Jack Net/sys admin More details about KWAOO can be found at: https://as24904.kwaoo.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From martin.hunek at lbcfree.net Fri Sep 22 11:27:04 2017 From: martin.hunek at lbcfree.net (Martin =?utf-8?B?SHVuxJtr?=) Date: Fri, 22 Sep 2017 11:27:04 +0200 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <397fd725-0403-dca7-539e-1550faa5e0e3@danysek.cz> References: <397fd725-0403-dca7-539e-1550faa5e0e3@danysek.cz> Message-ID: <3358850.07TYT8DNyD@rumburak> Hello, I don't think that there is anyone whom would not be able to justify /22. So I think that there should not be any need for justification. Simply because it would be one more meaningless paper, nothing more. Secondly, for me having more specific routes than /24 doesn't seems seem as the right solution for IPv4. More specific routes means more routes in table, so more resources spent on legacy protocol. As for the core of the proposal - droping maximal allocation size from /22 to /24: I don't think that keeping PA pool longer than needed is good for future of an Internet. Maybe it would be better to transfer more space in PI IX pool, drop the restrictions on that pool which prevents to use it for CGN and let the PA space run flat. Long story short, I'm aginst the 2017-03 policy as it is written right now. Best Regards, Martin Hunek Dne p?tek 22. z??? 2017 10:09:28 CEST, Daniel Suchy napsal(a): > Hello, > /24 is de-facto standard accepted in routing tables these days and also > /24 was used in large scale during PI assignments - so I don't see any > problem in reduction of initial (minimal) IPv4 allocation. So i support > this idea. > > But I would like to keep option for asking more than /24 (up to /22 > maximum, as was decided in the past) LIRs eligible for allocation, if > LIR properly documents his request. > > From my own practice there're some LIR, where /24 is sufficient and they > just become LIRs because there's no other real option to get independent > addresses (old "PI") and with /22 we're just wasting limited resource. > But there're also LIRs, where /22 will actively used. > > I don't see any problems in terms of RFC 2050 mentioned here and memory > contraints, providers had to upgrade their routers in meantime anyway > (at least due to IPv6 adoption). Fragmentation up to /24 is long-term > reality and we had to deal with it anyway. > > With regards, > Daniel > > On 09/21/2017 01:43 PM, Marco Schmidt wrote: > > Dear colleagues, > > > > A new RIPE Policy proposal, 2017-03, "Reducing Initial IPv4 Allocation, > > aiming to preserve a minimum of IPv4 space", is now available for > > discussion. > > > > The goal of this proposal is to reduce the IPv4 allocations made by the > > RIPE NCC to a /24 (currently a /22) and only to LIRs that have not > > received an IPv4 allocation directly from the RIPE NCC before. > > > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2017-03/ > > > > As per the RIPE Policy Development Process (PDP), the purpose of this > > four-week Discussion Phase is to discuss the proposal and provide feedback > > to the proposer. > > > > At the end of the Discussion Phase, the proposer, with the agreement of > > the RIPE Working Group Chairs, decides how to proceed with the proposal. > > > > We encourage you to review this proposal and send your comments to > > before 20 October 2017. > > > > Kind regards, > > > > Marco Schmidt > > Policy Development Officer > > RIPE NCC > > > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From anna.wilson at heanet.ie Fri Sep 22 14:56:13 2017 From: anna.wilson at heanet.ie (Anna Wilson) Date: Fri, 22 Sep 2017 13:56:13 +0100 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <99c23a41034545ebb5eef1c212ce128b@elisa.fi> References: <397fd725-0403-dca7-539e-1550faa5e0e3@danysek.cz> <99c23a41034545ebb5eef1c212ce128b@elisa.fi> Message-ID: <05D277B2-6F95-43C4-BB7A-D690F134DAB3@heanet.ie> Hi Ray, > On 22 Sep 2017, at 12:04, Jetten Raymond wrote: > > Hi Anna, > > I saw some calculations that with the current policy it would be 4-5 years, to run completely out, last /8 and returned space. > > Now I don?t know if these calculations are correct, but even if they are, or not, then I would like to know how long it should last ? 10 years, 20 , 50? > > I can see and understand your points, the original /8 proposal was not meant to delay v6, fully agree, but by spreading it now it will be expected to be spread out again in say 2-4 years (?) . > > I seriously think that the more time we get, or give the illusion that we can then rearrange it again, the more time people will ignore the fact that it will run out, regardless if we change the policy or not. I believe you are correct that people will ignore runout, regardless of whether we change the policy or not. My concern is that the problems of ignoring runout fall disproportionately not on existing holders who do the ignoring (who have a good chance of being able to rustle up a small amount of their existing space somewhere to run their IPv6 transition equipment) but on future new entrants (who would have no existing space to shuffle.) That's an externalised cost, and it is the very same externalised cost that I believe the original last /8 policy was intended to address. This proposal is the best way I can think to reduce that burden on new entrants. So to answer your first question: how long should it last? My only answer to that can be "for as long as new entrants need some IPv4 in order to use IPv6; or as long as possible if we can't get that far." We land on /24 because we think it's practical today. > Therefore I still think the current policy is sufficient. Forgive me if I misunderstand your thinking; I believe it's this: that full runout is the remaining tool we have to get existing IPv4 holders to deploy IPv6, so we should not take further actions to delay it. It's not an unreasonable effect to hope for. But the current /8 policy is already quite restrictive. I would be surprised if full runout would have a much greater effect on existing IPv4 holders. And even if that effect is something above negligible, the burden of it falls disproportionately on post-runout new entrants. So I think that's who we need to help, and why a policy change is needed. Best regards, Anna -- Anna Wilson Service Desk Manager HEAnet CLG, Ireland?s National Education and Research Network 1st Floor, 5 George?s Dock, IFSC, Dublin D01 X8N7, Ireland +353 (0)1 6609040 anna.wilson at heanet.ie www.heanet.ie Registered in Ireland, No. 275301. CRA No. 20036270 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom.hill at bytemark.co.uk Fri Sep 22 14:58:51 2017 From: tom.hill at bytemark.co.uk (Tom Hill) Date: Fri, 22 Sep 2017 13:58:51 +0100 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: <397fd725-0403-dca7-539e-1550faa5e0e3@danysek.cz> <99c23a41034545ebb5eef1c212ce128b@elisa.fi> Message-ID: On 22/09/17 12:11, jack at k-net.pro wrote: > Today at $work, there is nothing planned to get rid of IPv4. Why should > we ? Buying some is less expensive than working on hybrid solution. That actually raises a good point: consider the enterprise that has enough IPv4 addresses for the next 30 years of company operation. Perhaps they manufacture really nice deck chairs, or something. They won't be buying any IPv4, because they don't need any more. Does expensive IPv4 incentivise them to switch to IPv6? No. Companies of this ilk exist, and in their droves. None of them contribute to this list because they don't care one jot, as long as the WWW works. Bad IPv4 connectivity needs to break their access to the WWW before IPv6 will be anywhere on the list of that company's activities. This is _the_ business case for everyone, all the way from that situation, to those that are full blown ISPs: IPv4 needs to stop working before IPv6 will be considered by the vast majority of resource holders. It's primarily because of this that I'm against 2017-03: 1. It will not serve to improve IPv6 deployment 2. It may go as far as to seriously impact the size of the DFZ 3. I see no benefit over the current policy Regards, -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From anna.wilson at heanet.ie Fri Sep 22 15:16:24 2017 From: anna.wilson at heanet.ie (Anna Wilson) Date: Fri, 22 Sep 2017 14:16:24 +0100 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: <397fd725-0403-dca7-539e-1550faa5e0e3@danysek.cz> <99c23a41034545ebb5eef1c212ce128b@elisa.fi> Message-ID: <96B06EA5-F50E-4E91-B297-F6ABFE08E717@heanet.ie> Hi Tom, Thanks a lot for the thoughts. > It's primarily because of this that I'm against 2017-03: > > 1. It will not serve to improve IPv6 deployment My memory is that the original /8 policy was implemented, not to encourage/discourage IPv6 adoption among existing IPv4 holders, but because we recognised that new entrants joining the internet, even when IPv6 capable throughout, still require at least a little bit of IPv4. Best I can tell, that's still the case. So we're neutral on getting existing holders to shift, but I think this proposal is highly positive on the number of new entrants who'll be able to take this path. > 2. It may go as far as to seriously impact the size of the DFZ I don't want to dismiss the impact that RIR policies have on the DFZ (it's why we started making them, after all) but the DFZ ultimately operates on its own (very raw) consensus. Fragmented blocks do work today, down to /24 - and we have no idea how full runout will change the dynamics of already-routed blocks. So if fragmentation of the remaining /22s in the RIPE free pool may have a serious impact, then I'd suggest that we need to prepare for fragmentation, whether or not this policy is adopted. Of course, RIR policies do have an impact - but only for as long as the policies remain meaningful. Once the free pool is out, and fragmentation of existing blocks becomes the sole way to get more addresses, there's not much more we can do on this mailing list to affect the DFZ. > 3. I see no benefit over the current policy So in summary: the original last /8 was meant to get new entrants onto IPv6 by providing them a little bit of IPv4. I'd like this to continue for longer. Best regards, Anna -- Anna Wilson Service Desk Manager HEAnet CLG, Ireland?s National Education and Research Network 1st Floor, 5 George?s Dock, IFSC, Dublin D01 X8N7, Ireland +353 (0)1 6609040 anna.wilson at heanet.ie www.heanet.ie Registered in Ireland, No. 275301. CRA No. 20036270 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom.hill at bytemark.co.uk Fri Sep 22 15:28:05 2017 From: tom.hill at bytemark.co.uk (Tom Hill) Date: Fri, 22 Sep 2017 14:28:05 +0100 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <96B06EA5-F50E-4E91-B297-F6ABFE08E717@heanet.ie> References: <397fd725-0403-dca7-539e-1550faa5e0e3@danysek.cz> <99c23a41034545ebb5eef1c212ce128b@elisa.fi> <96B06EA5-F50E-4E91-B297-F6ABFE08E717@heanet.ie> Message-ID: <6f6c81ff-449c-a157-6766-a9205b27e37c@bytemark.co.uk> On 22/09/17 14:16, Anna Wilson wrote: >> 1. It will not serve to improve IPv6 deployment > > My memory is that the original /8 policy was implemented, not to > encourage/discourage IPv6 adoption among existing IPv4 holders, but > because we recognised that new entrants joining the internet, even when > IPv6 capable throughout, still require at least a little bit of IPv4. > Best I can tell, that's still the case. > > So we're neutral on getting existing holders to shift, but I think this > proposal is highly positive on the number of new entrants who'll be able > to take this path. The current 'last /8' policy is already doing what it was designed to do, as far as I can determine (and has been mentioned already). We're now beyond the time of making the 'last /8' policy, by many years, and I believe that we should be concentrating on making improvements to IPv6 - ensuring that it's an excellent future for all - instead of slicing IPv4 thinner. Picking-up the long tail of stubborn/disinterested organisations is going to be really fun. >> 2. It may go as far as to seriously impact the size of the DFZ > > I don't want to dismiss the impact that RIR policies have on the DFZ > (it's why we started making them, after all) but the DFZ ultimately > operates on its own (very raw) consensus. Fragmented blocks do work > today, down to /24 - and we have no idea how full runout will change the > dynamics of already-routed blocks. The concern was that once the minimum size is a /24, as proposed, there will be a need to permit /25 or /26 announcements to permit certain traffic engineering strategies. Not that /22s will continued to be disaggregated. Disaggregation to /24 is bad enough as it is, IMO. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From tjc at ecs.soton.ac.uk Fri Sep 22 15:39:01 2017 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Fri, 22 Sep 2017 14:39:01 +0100 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <05D277B2-6F95-43C4-BB7A-D690F134DAB3@heanet.ie> References: <397fd725-0403-dca7-539e-1550faa5e0e3@danysek.cz> <99c23a41034545ebb5eef1c212ce128b@elisa.fi> <05D277B2-6F95-43C4-BB7A-D690F134DAB3@heanet.ie> Message-ID: Hi, > On 22 Sep 2017, at 13:56, Anna Wilson wrote: > > Hi Ray, > >> On 22 Sep 2017, at 12:04, Jetten Raymond wrote: >> >> Hi Anna, >> >> I saw some calculations that with the current policy it would be 4-5 years, to run completely out, last /8 and returned space. >> >> Now I don?t know if these calculations are correct, but even if they are, or not, then I would like to know how long it should last ? 10 years, 20 , 50? >> >> I can see and understand your points, the original /8 proposal was not meant to delay v6, fully agree, but by spreading it now it will be expected to be spread out again in say 2-4 years (?) . >> >> I seriously think that the more time we get, or give the illusion that we can then rearrange it again, the more time people will ignore the fact that it will run out, regardless if we change the policy or not. > > I believe you are correct that people will ignore runout, regardless of whether we change the policy or not. > > My concern is that the problems of ignoring runout fall disproportionately not on existing holders who do the ignoring (who have a good chance of being able to rustle up a small amount of their existing space somewhere to run their IPv6 transition equipment) but on future new entrants (who would have no existing space to shuffle.) > > That's an externalised cost, and it is the very same externalised cost that I believe the original last /8 policy was intended to address. This proposal is the best way I can think to reduce that burden on new entrants. > > So to answer your first question: how long should it last? My only answer to that can be "for as long as new entrants need some IPv4 in order to use IPv6; or as long as possible if we can't get that far." We land on /24 because we think it's practical today. But it?s not really that they "need some IPv4 in order to use IPv6?. If they?re making content available, you need IPv4 whether you?re deploying dual-stack with IPv6 or not. If they?re deploying an IPv6-only access network, and using NAT64/DNS64/464XLAT to access legacy IPv4 content, then they?ll need less IPv4 if using IPv6, because a certain (growing) percentage of traffic will be native IPv6 and not NAT64?d (I see 30%-50% quoted in different scenarios, due to FB, Netflix, Google, etc). The more IPv6-cabable content out there, the less need for IPv4 addresses for a NAT64 service. So I think they really ?need some IPv4 in order to access other people?s IPv4-only content". That need may drop if more NAT64 (or encapsulating equivalents) is deployed, or more content is directly IPv6-enabled or hosted on IPv6-cpable CDNs like Cloudflare, Akamai, etc. There is some use of NAT46 (SIIT DC etc), but that seems pretty rare, at least currently. >> Therefore I still think the current policy is sufficient. > > Forgive me if I misunderstand your thinking; I believe it's this: that full runout is the remaining tool we have to get existing IPv4 holders to deploy IPv6, so we should not take further actions to delay it. > > It's not an unreasonable effect to hope for. But the current /8 policy is already quite restrictive. I would be surprised if full runout would have a much greater effect on existing IPv4 holders. Perhaps holders might sell off some space if there?s complete RIR runout, the IPv4 price rises, and the market is the only option. So there might be a feedback loop which would generate more supply? > And even if that effect is something above negligible, the burden of it falls disproportionately on post-runout new entrants. > > So I think that's who we need to help, and why a policy change is needed. The aim of the proposal is very well-intentioned. I?m just not convinced it will make any difference by 2021/22 when the current run-out for our region is projected. Things will have moved on significantly by then, just like they have for IPv6 between 2012 and 2017. There was effectively no IPv6 deployment 5 years ago. There?s an argument to track and follow policies implemented elsewhere, and keep in step with those. LACNIC has adopted /24 it seems, and ARIN have a /10 of IPv4 from which they can hand out /28 to /24. what are the current APNIC or AFRINIC policies? Tim > Best regards, > Anna > > -- > Anna Wilson > Service Desk Manager > HEAnet CLG, Ireland?s National Education and Research Network > 1st Floor, 5 George?s Dock, IFSC, Dublin D01 X8N7, Ireland > +353 (0)1 6609040 anna.wilson at heanet.ie www.heanet.ie > Registered in Ireland, No. 275301. CRA No. 20036270 > From frettled at gmail.com Fri Sep 22 15:40:04 2017 From: frettled at gmail.com (Jan Ingvoldstad) Date: Fri, 22 Sep 2017 15:40:04 +0200 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <6f6c81ff-449c-a157-6766-a9205b27e37c@bytemark.co.uk> References: <397fd725-0403-dca7-539e-1550faa5e0e3@danysek.cz> <99c23a41034545ebb5eef1c212ce128b@elisa.fi> <96B06EA5-F50E-4E91-B297-F6ABFE08E717@heanet.ie> <6f6c81ff-449c-a157-6766-a9205b27e37c@bytemark.co.uk> Message-ID: On Fri, Sep 22, 2017 at 3:28 PM, Tom Hill wrote: > The concern was that once the minimum size is a /24, as proposed, there > will be a need to permit /25 or /26 announcements to permit certain > traffic engineering strategies. Not that /22s will continued to be > disaggregated. Disaggregation to /24 is bad enough as it is, IMO. "Well, actually" This just means that "certain traffic engineering strategies" will no longer be viable for new entrants. -- Jan From tom.hill at bytemark.co.uk Fri Sep 22 15:51:53 2017 From: tom.hill at bytemark.co.uk (Tom Hill) Date: Fri, 22 Sep 2017 14:51:53 +0100 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: <397fd725-0403-dca7-539e-1550faa5e0e3@danysek.cz> <99c23a41034545ebb5eef1c212ce128b@elisa.fi> <96B06EA5-F50E-4E91-B297-F6ABFE08E717@heanet.ie> <6f6c81ff-449c-a157-6766-a9205b27e37c@bytemark.co.uk> Message-ID: <42bba37c-40b0-c0f9-0000-f74a4da20dae@bytemark.co.uk> On 22/09/17 14:40, Jan Ingvoldstad wrote: > This just means that "certain traffic engineering strategies" will no > longer be viable for new entrants. In my little corner of the world, it is the flexibility of those "traffic engineering strategies" that finally push entrants into obtaining IP space. I don't believe restricting that to a /24 and making the rest of us suffer with /26 announcements is going to help the us all in the long run. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From anna.wilson at heanet.ie Fri Sep 22 16:05:59 2017 From: anna.wilson at heanet.ie (Anna Wilson) Date: Fri, 22 Sep 2017 15:05:59 +0100 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <6f6c81ff-449c-a157-6766-a9205b27e37c@bytemark.co.uk> References: <397fd725-0403-dca7-539e-1550faa5e0e3@danysek.cz> <99c23a41034545ebb5eef1c212ce128b@elisa.fi> <96B06EA5-F50E-4E91-B297-F6ABFE08E717@heanet.ie> <6f6c81ff-449c-a157-6766-a9205b27e37c@bytemark.co.uk> Message-ID: <53F08B7A-6A00-496F-B798-FB5118945F9F@heanet.ie> Hi Tom, > On 22 Sep 2017, at 14:28, Tom Hill wrote: > > On 22/09/17 14:16, Anna Wilson wrote: >>> 1. It will not serve to improve IPv6 deployment >> >> My memory is that the original /8 policy was implemented, not to >> encourage/discourage IPv6 adoption among existing IPv4 holders, but >> because we recognised that new entrants joining the internet, even when >> IPv6 capable throughout, still require at least a little bit of IPv4. >> Best I can tell, that's still the case. >> >> So we're neutral on getting existing holders to shift, but I think this >> proposal is highly positive on the number of new entrants who'll be able >> to take this path. > > The current 'last /8' policy is already doing what it was designed to > do, as far as I can determine (and has been mentioned already). Oh yes, it is, and without further intervention it will continue to do so for a finite amount of time, then it will stop. So the proposal is to extend that finite time. > We're now beyond the time of making the 'last /8' policy, by many years, > and I believe that we should be concentrating on making improvements to > IPv6 - ensuring that it's an excellent future for all - instead of > slicing IPv4 thinner. Picking-up the long tail of stubborn/disinterested > organisations is going to be really fun. I agree but I don't understand why this is an either/or. This proposal doesn't stop that work. I'd gently suggest the counter: - that new entrants are most likely to support IPv6 (because very little IPv4 can be got); - that even fully IPv6-ed new entrants need some IPv4 to make IPv6 work; - reaching IPv4 runout while this is still the case will hurt those new entrants disproportionately; - and so the worst effects fall on those who are likely to be the biggest supporters of IPv6 anyway. >>> 2. It may go as far as to seriously impact the size of the DFZ >> >> I don't want to dismiss the impact that RIR policies have on the DFZ >> (it's why we started making them, after all) but the DFZ ultimately >> operates on its own (very raw) consensus. Fragmented blocks do work >> today, down to /24 - and we have no idea how full runout will change the >> dynamics of already-routed blocks. > > The concern was that once the minimum size is a /24, as proposed, there > will be a need to permit /25 or /26 announcements to permit certain > traffic engineering strategies. Not that /22s will continued to be > disaggregated. Disaggregation to /24 is bad enough as it is, IMO. I take the point that the immediate pressure to deaggregate /24s could increase. And on the other side, Nick is pointing out what a small proportion of address space this proposal would affect; but nonetheless, they're both genuine points. So the problem we face with the DFZ I think is not specifically "smallest prefix in the table" but "growth of number of entries over time." Entries over time keeps going up, and RIR policies have very successfully kept that growth contained. Right now, the number of additional DFZ entries under the existing last /8 policy is between 1 and 4 times the number of applications approved under that policy. (1 if no deaggregation, 4 if deaggregated into 4x/24.) Even in the scenario of deaggregation down to /26, this would remain the case under the new proposal: 1 entry if no deaggregation, 4 if deaggregated into 4x/26 (plus possible additional 4x deaggregation of the existing last /8 blocks.) And if this is done on foot of a RIPE policy, then it's possible to manage this deaggregation in a controlled manner based on the /8 boundary. If you then fear that this deaggregation would spread to the rest of the DFZ: yes, I share this fear. In fact I think we can be very sure that this is coming, one way or another; Randy explained how based on history earlier in the thread. But in a world of run-out, I don't know how to avoid it. What I do know is that for as long as RIPE allocates IPv4 space, we can make policies which provide the routing infrastructure with some boundaries to try to manage this deaggregation. Once we hit full runout, we lose that ability. Best regards, Anna -- Anna Wilson Service Desk Manager HEAnet CLG, Ireland?s National Education and Research Network 1st Floor, 5 George?s Dock, IFSC, Dublin D01 X8N7, Ireland +353 (0)1 6609040 anna.wilson at heanet.ie www.heanet.ie Registered in Ireland, No. 275301. CRA No. 20036270 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom.hill at bytemark.co.uk Fri Sep 22 16:37:14 2017 From: tom.hill at bytemark.co.uk (Tom Hill) Date: Fri, 22 Sep 2017 15:37:14 +0100 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <53F08B7A-6A00-496F-B798-FB5118945F9F@heanet.ie> References: <397fd725-0403-dca7-539e-1550faa5e0e3@danysek.cz> <99c23a41034545ebb5eef1c212ce128b@elisa.fi> <96B06EA5-F50E-4E91-B297-F6ABFE08E717@heanet.ie> <6f6c81ff-449c-a157-6766-a9205b27e37c@bytemark.co.uk> <53F08B7A-6A00-496F-B798-FB5118945F9F@heanet.ie> Message-ID: Hi Anna, On 22/09/17 15:05, Anna Wilson wrote: > - that new entrants are most likely to support IPv6 (because very little > IPv4 can be got); > - that even fully IPv6-ed new entrants need some IPv4 to make IPv6 work; > - reaching IPv4 runout while this is still the case will hurt those new > entrants disproportionately; The assertion that reducing the amount of IPv4 given will encourage those entrants to support IPv6 is tentative at best. The LIR entrance is a means to an end, and either it provides enough IPv4 for the task at hand, or it does not (ergo you seek another option). A stunning number of LIR applications are - as far as I can tell from this corner - from those that would have otherwise applied for IPv4 PI space. Any sane 'new entrant' (e.g. startup ISP/host) relying on the LIR application solely isn't going to succeed. Whether you give them 1024 or 256 addresses, it's just a per-address cost. It doesn't make IPv6 any more fit for the same purpose, or worth the engineering time at a point where your sole concentration is on not going bust. Because I don't see a way in which this policy will change anyone's behaviour, or incentivise them differently over the current policy, I don't believe it needs to be changed. If you would like, we can take IPv6 adoption out of the argument completely, and I can still be solely against it for the reason of changing the status quo on acceptable prefix sizes for no perceivable gain to anyone. > So the problem we face with the DFZ I think is not specifically > "smallest prefix in the table" but "growth of number of entries over > time." Entries over time keeps going up, and RIR policies have very > successfully kept that growth contained. "I've deaggregated our /19 to /24s to prevent hijacks." is the problem. Legitimate traffic engineering is not the issue here, it's the blatant disregard for the cost of TCAM across the DFZ versus the selfish/misguided security requirements of certain network operators. The concern is that those persons will, very quickly, deaggregate to the minimum possible prefix size. > If you then fear that this deaggregation would spread to the rest of the > DFZ: yes, I share this fear. In fact I think we can be very sure that > this is coming, one way or another; Randy explained how based on history > earlier in the thread. Yes, and I pointed out to Randy in response that the stakes are hell of a lot higher than they were in 1995. Like, "we're not the butt of all jokes" higher. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From anna.wilson at heanet.ie Fri Sep 22 16:50:20 2017 From: anna.wilson at heanet.ie (Anna Wilson) Date: Fri, 22 Sep 2017 15:50:20 +0100 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: <397fd725-0403-dca7-539e-1550faa5e0e3@danysek.cz> <99c23a41034545ebb5eef1c212ce128b@elisa.fi> <96B06EA5-F50E-4E91-B297-F6ABFE08E717@heanet.ie> <6f6c81ff-449c-a157-6766-a9205b27e37c@bytemark.co.uk> <53F08B7A-6A00-496F-B798-FB5118945F9F@heanet.ie> Message-ID: <0B3FF616-F266-495D-88E8-41190C660CEC@heanet.ie> Hi Tom, > On 22 Sep 2017, at 15:37, Tom Hill wrote: > > Because I don't see a way in which this policy will change anyone's > behaviour, or incentivise them differently over the current policy, I > don't believe it needs to be changed. If you would like, we can take > IPv6 adoption out of the argument completely, and I can still be solely > against it for the reason of changing the status quo on acceptable > prefix sizes for no perceivable gain to anyone. The proposal doesn't have a goal of changing anyone's behaviour or incentivising anyone. The goal is to quadruple the number of remaining IPv4 applications that RIPE NCC can fulfil. So the gain is to those three quarters of applications that would otherwise be unsuccessful. >> So the problem we face with the DFZ I think is not specifically >> "smallest prefix in the table" but "growth of number of entries over >> time." Entries over time keeps going up, and RIR policies have very >> successfully kept that growth contained. > > "I've deaggregated our /19 to /24s to prevent hijacks." is the problem. > > Legitimate traffic engineering is not the issue here, it's the blatant > disregard for the cost of TCAM across the DFZ versus the > selfish/misguided security requirements of certain network operators. > > The concern is that those persons will, very quickly, deaggregate to the > minimum possible prefix size. It's a fair concern; I suggest filters specific to the last /8 boundary as a way to contain the risk. >> If you then fear that this deaggregation would spread to the rest of the >> DFZ: yes, I share this fear. In fact I think we can be very sure that >> this is coming, one way or another; Randy explained how based on history >> earlier in the thread. > > Yes, and I pointed out to Randy in response that the stakes are hell of > a lot higher than they were in 1995. Like, "we're not the butt of all > jokes" higher. I hear you. I think it even supports your point in this case- if deaggregation could spread when the stakes were lower, we may be very sure that it'll spread when the stakes are higher. I hope I was able to address that point in the surrounding paragraphs. Best regards, Anna -- Anna Wilson Service Desk Manager HEAnet CLG, Ireland?s National Education and Research Network 1st Floor, 5 George?s Dock, IFSC, Dublin D01 X8N7, Ireland +353 (0)1 6609040 anna.wilson at heanet.ie www.heanet.ie Registered in Ireland, No. 275301. CRA No. 20036270 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mschmidt at ripe.net Fri Sep 22 16:55:14 2017 From: mschmidt at ripe.net (Marco Schmidt) Date: Fri, 22 Sep 2017 16:55:14 +0200 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: Message-ID: Hello Tim, On 2017-09-22 15:39:01 CET, Tim Chown wrote: > There?s an argument to track and follow policies implemented elsewhere, and keep in step with those. LACNIC has adopted /24 it seems, and ARIN have a /10 of IPv4 from which they can hand out /28 to /24. what are the current APNIC or AFRINIC policies? > I am happy to provide some information here. In the AFRINIC region, in the final exhaustion phase, the minimum allocation/assignment size will be a /24, and the maximum will be a /22 per allocation/assignment. https://www.afrinic.net/library/policies/1829-afrinic-consolidated-policy-manual#s5_4 In the APNIC region, the minimum allocation size for IPv4 is a /24. Each APNIC account holder is eligible to receive IPv4 allocations totalling a maximum /22 from the APNIC 103/8 IPv4 address pool (Final /8 Block) and additional allocations up to a maximum of /22 address space from the APNIC non-103/8 IPv4 address pool. https://www.apnic.net/community/policy/resources#Part-2:-IPv4-Policy I hope this clarifies your question. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From zenker at punkt.de Fri Sep 22 18:25:19 2017 From: zenker at punkt.de (Wolfgang Zenker) Date: Fri, 22 Sep 2017 18:25:19 +0200 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: Message-ID: On 2017-09-22 14:58:51 CET, Tom Hill wrote: > On 22/09/17 12:11, jack _at_ k-net _dot_ pro wrote: >> Today at $work, there is nothing planned to get rid of IPv4. Why should >> we ? Buying some is less expensive than working on hybrid solution. > That actually raises a good point: consider the enterprise that has > enough IPv4 addresses for the next 30 years of company operation. > Perhaps they manufacture really nice deck chairs, or something. They > won't be buying any IPv4, because they don't need any more. > Does expensive IPv4 incentivise them to switch to IPv6? No. > Companies of this ilk exist, and in their droves. None of them > contribute to this list because they don't care one jot, as long as the > WWW works. Bad IPv4 connectivity needs to break their access to the WWW > before IPv6 will be anywhere on the list of that company's activities. We are getting there. Reachability of IPv4-only services is already degrading, with some(?) access carriers not operating their CGN gateways at the capacity needed for peak traffic times. Not least because they simply don't have enough IPv4 addresses to do that. Rearding the proposed policy change I don't think it will really buy us a lot more time: Those members that use the existing policy to "buy" addresses by starting new LIRs will simply start 4 times as many new LIRs. On the other hand it won't do much harm either: De-aggregating of IPv4 space will continue anyway. So I'm undecided on the proposal. Greetings, Wolfgang Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From farmer at umn.edu Fri Sep 22 18:24:26 2017 From: farmer at umn.edu (David Farmer) Date: Fri, 22 Sep 2017 11:24:26 -0500 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: <861BFD37-7987-43B8-A459-4478E154AA21@ecs.soton.ac.uk> Message-ID: On Fri, Sep 22, 2017 at 5:04 AM, Tim Chown wrote: > ... and ARIN are on a last /10 policy which sees applicants get a /28 to a > /24, so presumably those /28?s are routed at some level; that?s been in > place for some time, how is it working out? ... > This ARIN policy is in section 4.10 of ARIN's NRPM; https://www.arin.net/policy/nrpm.html#four10 This policy specifically envision the day when smaller than /24 blocks become routable and/or there could be non-routed needs for globally unique IPv4 addresses, in either of those cases it would be wasteful to assign a whole /24. Currently if a routable block is needed, which is typically the case, ARIN's operational practice is to assign a /24. However, if or when, smaller blocks become generally routable, no policy change is necessary for ARIN Staff to change it's operational practice. Further, it should be noted that to access that pool of IPv4 resources, a justification as to how the IPv4 addresses will be used to support the immediate deployment of IPv6 is necessary. Use of that pool to simply deploy more IPv4 addresses does not conform to the intent of this policy. Further, if an organization, already has access to IPv4 resources of any kind, there is a strong presumption they don't need to access this pool. Thanks -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From pk at DENIC.DE Fri Sep 22 20:04:27 2017 From: pk at DENIC.DE (Peter Koch) Date: Fri, 22 Sep 2017 20:04:27 +0200 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <05D277B2-6F95-43C4-BB7A-D690F134DAB3@heanet.ie> References: <397fd725-0403-dca7-539e-1550faa5e0e3@danysek.cz> <99c23a41034545ebb5eef1c212ce128b@elisa.fi> <05D277B2-6F95-43C4-BB7A-D690F134DAB3@heanet.ie> Message-ID: <20170922180427.GN11532@x27.adm.denic.de> Anna, all, On Fri, Sep 22, 2017 at 01:56:13PM +0100, Anna Wilson wrote: > It's not an unreasonable effect to hope for. But the current /8 policy is already quite restrictive. I would be surprised if full runout would have a much greater effect on existing IPv4 holders. And even if that effect is something above negligible, the burden of it falls disproportionately on post-runout new entrants. do we know how many LIRs eligible under the current policy have not yet asked for a final /22? -Peter From kranjbar at ripe.net Fri Sep 22 20:09:00 2017 From: kranjbar at ripe.net (Kaveh Ranjbar) Date: Fri, 22 Sep 2017 15:09:00 -0300 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: <861BFD37-7987-43B8-A459-4478E154AA21@ecs.soton.ac.uk> Message-ID: <2878B90B-9396-4229-B907-A5E9A3EF2F60@ripe.net> > On 22 Sep 2017, at 13:24, David Farmer wrote: > > On Fri, Sep 22, 2017 at 5:04 AM, Tim Chown wrote: > ... and ARIN are on a last /10 policy which sees applicants get a /28 to a /24, so presumably those /28?s are routed at some level; that?s been in place for some time, how is it working out? ... > > This ARIN policy is in section 4.10 of ARIN's NRPM; > > https://www.arin.net/policy/nrpm.html#four10 Hello WG, To shed some more light on routability of prefixes longer than /24, we started an experiment when the aforementioned policy change was being discussed at ARIN. From October 2014, we started announcing 6 prefixes from ARIN?s designated block 23.128/10. There are /24, /25 and /28 prefixes, with and without IRR objects. We then measured visibility and reachability of those prefixes both on the control plane (by looking at BGP) and on the data plane (using RIPE Atlas trace routes). You can find the original paper by Emile Aben at https://labs.ripe.net/Members/emileaben/propagation-of-longer-than-24-ipv4-prefixes as well as a followup in 2015 https://labs.ripe.net/Members/emileaben/has-the-routability-of-longer-than-24-prefixes-changed and finally, a more recent followup by Stephen Strowes on 10th of July 2017: https://labs.ripe.net/Members/stephen_strowes/bgp-even-more-specifics-in-2017 All the best, Kaveh. ??? Kaveh Ranjbar, Chief Information Officer, RIPE NCC. From Kohlstetter at hessenkom.de Fri Sep 22 22:12:30 2017 From: Kohlstetter at hessenkom.de (Peer Kohlstetter) Date: Fri, 22 Sep 2017 20:12:30 +0000 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: Message-ID: Hello WG, the discussion shows that there are a lot of pros and cons about this proposal. But the strongest argument for me is that we will have IPv4 around for very long time and this proposal help to gives every newcomer a fair start. That's the main Idea of the last /8. Because of this I support the proposal. The IPv4 world with BGP, NAT, CGN and IPv4 Transfers has shown big adaptability. If the best argument for IPv6 rollout is the end of the IPv4 world, we have to wait very long for a widely used IPv6 Internet. IPv4 is a very robust beast. Because of this we use and love it. :-) Best regards, Peer -------------------------------------------- blue networks GmbH & Co KG Peer Kohlstetter Mail: kohlstetter at blue-networks.de From wusel+ml at uu.org Fri Sep 22 22:31:27 2017 From: wusel+ml at uu.org (Kai 'wusel' Siering) Date: Fri, 22 Sep 2017 22:31:27 +0200 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <0B3FF616-F266-495D-88E8-41190C660CEC@heanet.ie> References: <397fd725-0403-dca7-539e-1550faa5e0e3@danysek.cz> <99c23a41034545ebb5eef1c212ce128b@elisa.fi> <96B06EA5-F50E-4E91-B297-F6ABFE08E717@heanet.ie> <6f6c81ff-449c-a157-6766-a9205b27e37c@bytemark.co.uk> <53F08B7A-6A00-496F-B798-FB5118945F9F@heanet.ie> <0B3FF616-F266-495D-88E8-41190C660CEC@heanet.ie> Message-ID: Hi, am 22.09.2017 um 16:50 schrieb Anna Wilson: > Hi Tom, > >> On 22 Sep 2017, at 15:37, Tom Hill > wrote: >> >> Because I don't see a way in which this policy will change anyone's >> behaviour, or incentivise them differently over the current policy, I >> don't believe it needs to be changed. If you would like, we can take >> IPv6 adoption out of the argument completely, and I can still be solely >> against it for the reason of changing the status quo on acceptable >> prefix sizes for no perceivable gain to anyone. > > The proposal doesn't have a goal of changing anyone's behaviour or incentivising anyone. The goal is to quadruple the number of remaining IPv4 applications that RIPE NCC can fulfil. > > So the gain is to those three quarters of applications that would otherwise be unsuccessful. As pointed out by others already, the change from /22 to /24 just quadruples the per-IP price tag. Due to the cost involved, 2017-03 may shortly reduce the amount of IPv4 space assigned to "new entrants". From my perspective, this effect will be short lived, as simply more "PI-LIRs" will be created to get IPv4 space before it's gone (and/or getting even more expensive). > I'd gently suggest the counter: > > - that new entrants are most likely to support IPv6 (because very little IPv4 can be got); If you finally hold your expensive v4 space, best to make it work for the money. But each new dual-stacked or, worse, v4-only service and user lessens the pressure on anyone to switch to v6. > - that even fully IPv6-ed new entrants need some IPv4 to make IPv6 work; I've read this point multiple times in this thread; but which part of IPv6 needs public IPv4 addresses to make IPv6 work? These are completely independent protocols (which is part of the problem and part of the solution ;)), used to create independent networks. > - reaching IPv4 runout while this is still the case will hurt those new entrants disproportionately; Isn't this the way of live? IPv4 is considered legacy, and the RIRs do a tremendous job at prolonging it's life span with their last /8 policies. But IPv4 has no future, it's address space is effectively gone (except for 240/4 ?). How long shall we prolong IPv4's infirmity? At current rate (and policies), RIPE NCC will run out of IPv4 addresses to allocate somewhere around 2020 or 2021? This was meant to happen some time, and it will happen some time, regardless of the policy in place. Another issue I see with the proposed policy: With 2017-03 in place, new LIRs[1] would be severly restricted in their business options, compared to ripe-680. I see no change in the situation since the last /8 policy went into effect that would justify this. Everything runs as expected. I'd support a change of 5.2, though: instead of serving the last 64 LIRs with a /22, use that /16 for 256 /24 allocations (or less, depending on routability at that point) along ARINs current policy[2]. Regards, -kai [1] https://www.ripe.net/manage-ips-and-asns/resource-management/faq/independent-resources/def-terms [2] https://www.arin.net/policy/nrpm.html#four10 -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfriacas at fccn.pt Sat Sep 23 01:02:55 2017 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Sat, 23 Sep 2017 00:02:55 +0100 (WEST) Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <20170922180427.GN11532@x27.adm.denic.de> References: <397fd725-0403-dca7-539e-1550faa5e0e3@danysek.cz> <99c23a41034545ebb5eef1c212ce128b@elisa.fi> <05D277B2-6F95-43C4-BB7A-D690F134DAB3@heanet.ie> <20170922180427.GN11532@x27.adm.denic.de> Message-ID: Hi Peter, All, On Fri, 22 Sep 2017, Peter Koch wrote: > Anna, all, > > On Fri, Sep 22, 2017 at 01:56:13PM +0100, Anna Wilson wrote: > >> It's not an unreasonable effect to hope for. But the current /8 policy is already quite restrictive. I would be surprised if full runout would have a much greater effect on existing IPv4 holders. And even if that effect is something above negligible, the burden of it falls disproportionately on post-runout new entrants. > > do we know how many LIRs eligible under the current policy have not > yet asked for a final /22? > > -Peter Thanks for that question! Looking at the alloclist from today, and filtering for RegIDs, i can count: 16354 (hmmm... # on https://labs.ripe.net/statistics is 16825, seems i'm mising something...) But anyway... the number of IPv4 /22s is 15391. From that number: 195 in Sept/2012 after the runout date. 595 in Q4/2012 (runout was in september) 1854 in 2013 2441 in 2014 3178 in 2015 3258 in 2016 2429 in 2017, so far. So, 13950 /22s between Q4/2012 and today, hence i would say your answer is around 2404 LIRs (16354-13950). ps: Someone at the NCC might have looked deeply into this, or not. :-) Regards, Carlos Fria?as From randy at psg.com Sat Sep 23 01:05:14 2017 From: randy at psg.com (Randy Bush) Date: Sat, 23 Sep 2017 08:05:14 +0900 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: <397fd725-0403-dca7-539e-1550faa5e0e3@danysek.cz> <99c23a41034545ebb5eef1c212ce128b@elisa.fi> <05D277B2-6F95-43C4-BB7A-D690F134DAB3@heanet.ie> <20170922180427.GN11532@x27.adm.denic.de> Message-ID: >> do we know how many LIRs eligible under the current policy have not >> yet asked for a final /22? > So, 13950 /22s between Q4/2012 and today, hence i would say your > answer is around 2404 LIRs (16354-13950). i tend to agree with the suggestion that folk with ipv4 space already are not eligible randy From randy at psg.com Sat Sep 23 02:24:55 2017 From: randy at psg.com (Randy Bush) Date: Sat, 23 Sep 2017 09:24:55 +0900 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <96B06EA5-F50E-4E91-B297-F6ABFE08E717@heanet.ie> References: <397fd725-0403-dca7-539e-1550faa5e0e3@danysek.cz> <99c23a41034545ebb5eef1c212ce128b@elisa.fi> <96B06EA5-F50E-4E91-B297-F6ABFE08E717@heanet.ie> Message-ID: it might be wise to avoid the eternal rat-hole of what will and will not increase ipv6 deployment. whether we like it or not, and whether we excoriate the folk who have not deployed or not, history has shown that we do not know. there are no more 32-bit integers. ipv6 is horrifyingly and tragically slow to deploy. get over it. get a life. those of us who have been around a while have heard it all before. raise your hand if you remember when 3gpp was going for force global ipv6 deployment. shall i start down the list of the other things? [ remember my $dayjob deployed in 1997 and my co-worker wrote the kame stack on which many of your ipv6 implementations are based. ] the point here is simple. the ripe community has a responsibility to the human community beyond the members of this list. as a friend wrote privately I would be interested to have a person who is 16 years old reply: "I am planning to open my own internet company in 4 years; can you please save some address space for me, 'til I finish high school?" But of course, there is no such person on the RIPE mailing list.. and we are responsible to those 14 year olds. it is called stewardship. randy From randy at psg.com Sat Sep 23 02:32:02 2017 From: randy at psg.com (Randy Bush) Date: Sat, 23 Sep 2017 09:32:02 +0900 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <94134759.9xlNH3TRUR@rumburak> References: <94134759.9xlNH3TRUR@rumburak> Message-ID: > I don't think that there is anyone whom would not be able to justify > /22. i think there are a vast number of entities which could justify a /16. so? there is this little problem. 2^32 is bounded. randy From wusel+ml at uu.org Sat Sep 23 03:40:56 2017 From: wusel+ml at uu.org (Kai 'wusel' Siering) Date: Sat, 23 Sep 2017 03:40:56 +0200 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: <397fd725-0403-dca7-539e-1550faa5e0e3@danysek.cz> <99c23a41034545ebb5eef1c212ce128b@elisa.fi> <96B06EA5-F50E-4E91-B297-F6ABFE08E717@heanet.ie> Message-ID: <212ed71f-afc9-4913-e1cf-7f4a7127c4ca@uu.org> Am 23.09.2017 um 02:24 schrieb Randy Bush: > the point here is simple. the ripe community has a responsibility to > the human community beyond the members of this list. But the RIPE Community cannot change the laws of physics or, for that matter, math. 2?? just wasn't enough numbers, deal with it. > as a friend wrote privately > > I would be interested to have a person who is 16 years old reply: > > "I am planning to open my own internet company in 4 years; can you > please save some address space for me, 'til I finish high school?" > > But of course, there is no such person on the RIPE mailing list.. > > and we are responsible to those 14 year olds. If he has the money to become a RIPE LIR right out of school, he *might* still get a /22 by then. Note, though, "internet company" does not necessarily involve IPv4. Nor does it mean that he has to become an LIR; actually, many LIRs will be around that can supply him with v4 PA space and connectivity, e. g. those LIRs that existed before A6 and ip6.int got deprecated ... Now, the children of my offsprings, which might have still a decade or so to conception, what's with them? How do you intend to steward v4 usage to ensure them the same chances to "open their own internet company" in, say, 28 years? Or, more likely, their potential parents in, say, 8 years from now, after them finishing School and University? Where does this 'responsibily' end? When will be "well, the IPv4 well dried out back in 2011; it's now just done, you're simply too late" a 'responsible' answer? If not 2020/2021 (as based on current prediction), how about 2022? 2030? 2080? When do we distribute 240/4 among the RIRs as "really last /8s"? Seriously, this is ridiculous. IPv4 is done. "get over it. get a life." And deploy IPv6. Actually a common tune[1] a decade before today already ;) Regards, -kai [1] https://www.youtube.com/watch?v=_y36fG2Oba0 From randy at psg.com Sat Sep 23 07:38:30 2017 From: randy at psg.com (Randy Bush) Date: Sat, 23 Sep 2017 14:38:30 +0900 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <212ed71f-afc9-4913-e1cf-7f4a7127c4ca@uu.org> References: <397fd725-0403-dca7-539e-1550faa5e0e3@danysek.cz> <99c23a41034545ebb5eef1c212ce128b@elisa.fi> <96B06EA5-F50E-4E91-B297-F6ABFE08E717@heanet.ie> <212ed71f-afc9-4913-e1cf-7f4a7127c4ca@uu.org> Message-ID: >> as a friend wrote privately >> I would be interested to have a person who is 16 years old reply: >> "I am planning to open my own internet company in 4 years; can you >> please save some address space for me, 'til I finish high school?" >> But of course, there is no such person on the RIPE mailing list.. >> and we are responsible to those 14 year olds. > If he has the money to become a RIPE LIR right out of school he? wrong. From cfriacas at fccn.pt Sat Sep 23 10:04:31 2017 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Sat, 23 Sep 2017 09:04:31 +0100 (WEST) Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <212ed71f-afc9-4913-e1cf-7f4a7127c4ca@uu.org> References: <397fd725-0403-dca7-539e-1550faa5e0e3@danysek.cz> <99c23a41034545ebb5eef1c212ce128b@elisa.fi> <96B06EA5-F50E-4E91-B297-F6ABFE08E717@heanet.ie> <212ed71f-afc9-4913-e1cf-7f4a7127c4ca@uu.org> Message-ID: Hi, On Sat, 23 Sep 2017, Kai 'wusel' Siering wrote: (...) > Where does this 'responsibily' end? Don't know, but still feel we should try for the coming years. > When will be "well, the IPv4 well dried out back in 2011; It didn't completely (even today), but the RIPE NCC service region entered "scarcity-mode" in Sept'2012. > it's now just done, you're simply too late" a 'responsible' answer? If > not 2020/2021 (as based on current prediction), how about 2022? 2030? > 2080? If two years of more v6 deployment help, there is some benefit. If it's 10 more years, great. v6 deployment is slow -- that we know. > When do we distribute 240/4 among the RIRs as "really last /8s"? I made that question myself during an ICANN meeting (the only i attended) 10 years ago. The answer was something about operating systems' stacks. I wasn't fully convinced, but a large majority of internet plumbers seems to buy it... > Seriously, this is ridiculous. IPv4 is done. For expanding the Internet, sure. There is however, a tiny annoying bit: IPv4 is still the dominant Internet Protocol version in terms of usage :/ > "get over it. get a life." And deploy IPv6. Been there, done that. Sometimes i see some of it going back to IPv4-only, though :( And the biggest issue, we can't really force 3rd parties do deploy it. If some of those 3rd parties don't need to grow their infrastructures, the "incentive" to deploy IPv6 is really small :/ > Actually a common tune[1] a decade before today already ;) I actually was in the room when that happenned! :-)) On 26th Oct'2007 [1][2]. [1] https://www.ripe.net/participate/meetings/ripe-meetings/ripe-55 [2] https://www.ripe.net/participate/meetings/ripe-meetings/ripe-55/attendee-list Thanks for your input. Cheers, Carlos > Regards, > -kai > > [1] https://www.youtube.com/watch?v=_y36fG2Oba0 > > > From randy at psg.com Sat Sep 23 10:48:42 2017 From: randy at psg.com (Randy Bush) Date: Sat, 23 Sep 2017 17:48:42 +0900 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: <397fd725-0403-dca7-539e-1550faa5e0e3@danysek.cz> <99c23a41034545ebb5eef1c212ce128b@elisa.fi> <96B06EA5-F50E-4E91-B297-F6ABFE08E717@heanet.ie> <212ed71f-afc9-4913-e1cf-7f4a7127c4ca@uu.org> Message-ID: >> When do we distribute 240/4 among the RIRs as "really last /8s"? > > I made that question myself during an ICANN meeting (the only i > attended) 10 years ago. The answer was something about operating > systems' stacks. I wasn't fully convinced, but a large majority of > internet plumbers seems to buy it... analogous to one's need for ipv4 reachability until the last ipv4 sites die out, if any equipment does not properly route and forward 240/4 then there will be folk who can not reach those with addresses drawn from that space. darned shame but we do need universal reachability. we do not have a good track record for addressing architectures. check out rfc 2450 when you have not eaten recently. randy From mangawilly at gmail.com Sat Sep 23 21:54:01 2017 From: mangawilly at gmail.com (Willy MANGA) Date: Sat, 23 Sep 2017 20:54:01 +0100 Subject: [address-policy-wg] 2017-03, New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: Message-ID: <7a584263-a004-8aaf-544a-108b30001581@gmail.com> Hi, Le 22/09/2017 ? 08:47, address-policy-wg-request at ripe.net a ?crit?: > [...] > I'm working around IPv6 since 2001. Anna and Randy probably since before > that. We have deployed IPv6. It didn't enable us to completely get rid of > IPv4 within our networks. That also didn't solve any issue for 3rd party > networks -- they all still need IPv4 addresses. being a newbie here can you please explain briefly why, as of today , these people really need IPv4 addresses ? Or at least why they cannot start a transition process towards IPv6? Regards, -- Willy Manga @ongolaboy https://ongola.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From nick at foobar.org Sat Sep 23 22:41:12 2017 From: nick at foobar.org (Nick Hilliard) Date: Sat, 23 Sep 2017 21:41:12 +0100 Subject: [address-policy-wg] 2017-03, New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <7a584263-a004-8aaf-544a-108b30001581@gmail.com> References: <7a584263-a004-8aaf-544a-108b30001581@gmail.com> Message-ID: <59C6C6E8.1000407@foobar.org> Willy MANGA wrote: > being a newbie here can you please explain briefly why, as of today , > these people really need IPv4 addresses ? I'd be tempted to answer, except that you sent this email from an ipv4 address. So, please deconfigure all IPv4 addresses from your computer, re-send the email, and then I'll answer. > Or at least why they cannot > start a transition process towards IPv6? Without ipv4 addresses, transition technologies don't work. Nick From willy.manga at auf.org Sat Sep 23 23:51:28 2017 From: willy.manga at auf.org (Willy MANGA) Date: Sat, 23 Sep 2017 22:51:28 +0100 Subject: [address-policy-wg] 2017-03, New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <59C6C6E8.1000407@foobar.org> References: <7a584263-a004-8aaf-544a-108b30001581@gmail.com> <59C6C6E8.1000407@foobar.org> Message-ID: Hi Nick, Le 23/09/2017 ? 21:41, Nick Hilliard a ?crit?: > Willy MANGA wrote: >> being a newbie here can you please explain briefly why, as of today , >> these people really need IPv4 addresses ? > > I'd be tempted to answer, except that you sent this email from an ipv4 > address. So, please deconfigure all IPv4 addresses from your computer, > re-send the email, and then I'll answer. >From where I stand (at home in Cameroon, Central Africa), My ISP has /32 on v6 since 2013 but nothing deployed. Why ? I suspect ignorance and no incentive. I use to poke some friends working in telco fields; they say they are some work in the background :) >From where I work, I did my best to deploy IPv6 in our networks [1] [2] Our ISP here has its v6 prefix since ... 11 years. We are its first customer requesting v6 and they deploy it for us. I keep pushing in my area but as you may guess, it's the most difficult one but I succeed at least in my organisation. So again, why do they rely on v4 (only) ? I really want to understand hurdles on european continent. I hope this time, it will be clearer :) 1. https://nda.manbene.net/index.php/s/JJPCt8OVzoxNXCv (english) 2. https://nda.manbene.net/index.php/s/j5himX7Bfjk7OaV (french) >> Or at least why they cannot >> start a transition process towards IPv6? > > Without ipv4 addresses, transition technologies don't work. Assuming those who request v4 addresses have a transition plan (what I deeply hope ... ) P.S : This time I use my v6 smtp server even though at home I cannot still use a v6 prefix ;) From nick at foobar.org Sun Sep 24 00:32:09 2017 From: nick at foobar.org (Nick Hilliard) Date: Sat, 23 Sep 2017 23:32:09 +0100 Subject: [address-policy-wg] 2017-03, New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: <7a584263-a004-8aaf-544a-108b30001581@gmail.com> <59C6C6E8.1000407@foobar.org> Message-ID: <59C6E0E9.2000501@foobar.org> Willy MANGA wrote: > So again, why do they rely on v4 (only) ? I really want to understand > hurdles on european continent. > > I hope this time, it will be clearer :) same reason as in africa: for most organisations it's too much work with too little return. Many humans will only react after a crisis hits, even if the cost of that is higher overall. Nick From sander at steffann.nl Sun Sep 24 00:38:00 2017 From: sander at steffann.nl (Sander Steffann) Date: Sun, 24 Sep 2017 00:38:00 +0200 Subject: [address-policy-wg] 2017-03, New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: <7a584263-a004-8aaf-544a-108b30001581@gmail.com> <59C6C6E8.1000407@foobar.org> Message-ID: <8F620286-4C3F-443E-82FC-56F2F13F1CF0@steffann.nl> Hi, > So again, why do they rely on v4 (only) ? I really want to understand > hurdles on european continent. I think the hurdles are roughly the same in all regions. Relying on only IPv4 is insanity, and those that do so deserve no sympathy. But as you have personally experienced IPv6 isn't available everywhere and for everything yet. Therefore everybody still needs some IPv4 to communicate with those laggards. This community has so far considered it its responsibility (statement based on current policy) to make sure new entrants can do so without having to rely on getting IPv4 addresses through/from third parties. For almost all participants on the internet having at least some IPv4 space is vital for at least the next decade. What they get is a tiny amount of IPv4 space from RIPE NCC when they sign up as LIR. So far that tiny amount has been a /22. Now that the end of those /22s is in sight this community has to choose. Either keep the current policy and let it run out completely and let newcomers fend for themselves (if possible, 32-bit space is finite and at some point the market will dry up and IPv4 space will become unavailable/unaffordable) or change the /22 to /24 and keep giving newcomers a tiny bit of addresses for a while longer (what is currently being proposed). This community doesn't face an easy choice: keeping some IPv4 addresses available for newcomers can send the wrong message, that IPv4 hasn't "really" run out. Letting RIPE NCC run out completely will definitely fix that. On the other hand that will also send the message that the current internet participants want to keep newcomers out, or at last dependent on the willingness of current participant to part with some of their address space. That can be seen as anti-competitive and unfair. I really understand both sides of that argument (as I should, being a chair!). In both scenarios relying on only IPv4 is insanity, and I have a strong feeling that this community does not have the slightest bit of sympathy for those planning to do so. They are beyond help, so let them spend their own money on a failing technology. Any sympathy is for those who come to the party late but still have to deal with the laggards (and idiots) already present. > Assuming those who request v4 addresses have a transition plan (what I deeply hope ... ) One would indeed hope so. > P.S : This time I use my v6 smtp server even though at home I cannot still use a v6 prefix ;) :) Cheers! Sander From wusel+ml at uu.org Sun Sep 24 04:38:03 2017 From: wusel+ml at uu.org (Kai 'wusel' Siering) Date: Sun, 24 Sep 2017 04:38:03 +0200 Subject: [address-policy-wg] 2017-03, New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: <7a584263-a004-8aaf-544a-108b30001581@gmail.com> <59C6C6E8.1000407@foobar.org> Message-ID: <08fd41e5-7bb0-539b-3d49-4c2b05e2042d@uu.org> Hi, am 23.09.2017 um 23:51 schrieb Willy MANGA: > Hi Nick, > > Le 23/09/2017 ? 21:41, Nick Hilliard a ?crit : >> Willy MANGA wrote: >>> being a newbie here can you please explain briefly why, as of today , >>> these people really need IPv4 addresses ? >> I'd be tempted to answer, except that you sent this email from an ipv4 >> address. So, please deconfigure all IPv4 addresses from your computer, >> re-send the email, and then I'll answer. > From where I stand (at home in Cameroon, Central Africa), My ISP has /32 > on v6 since 2013 but nothing deployed. Why ? I suspect ignorance and no > incentive. > I use to poke some friends working in telco fields; they say they are > some work in the background :) > > From where I work, I did my best to deploy IPv6 in our networks [1] [2] > Our ISP here has its v6 prefix since ... 11 years. We are its first > customer requesting v6 and they deploy it for us. > > I keep pushing in my area but as you may guess, it's the most difficult > one but I succeed at least in my organisation. > > So again, why do they rely on v4 (only) ? I really want to understand > hurdles on european continent. > > I hope this time, it will be clearer :) Oh, the question was clear already; the answer was a bit of a puzzle. There are two Internets these days, the really old, 32 bit one, and the other one, based on 128 bit addressing. Different infrastructures, that can run alongside each other over the same cable, but don't know of the other. As you've noticed yourself already, IPv6 adoption is slow. So there's less incentive to run services on IPv6, which increases the need for IPv4 addresses. It's not too difficult to predict that IPv4-only services and servers will be around for the next decades. As you already have IPv4 and IPv6 address space, you can run Dual Stack, e. g. have v4 (maybe NATed) and v6 on each client, so each of your client systems can reach v4 and v6 destinations. If you don't have any publicly routed v4 address, you're be restricted to the upcoming, nice-and-shiny, IPv6-based, end-to-end Internet. Which, unfortunately, is only a subset of what is available in the rusty, IPv4-based, initial version. I recently tried it myself, setting up a VM for an audience that "usually" is v6-enabled, so I thought "cut the crap, we do this one v6-only". So the VM only received v6 networking. And then I tried to update it to the current patchlevel ? and I noticed that v4 is still a necessity: root at discourse:~# host de.archive.ubuntu.com de.archive.ubuntu.com is an alias for ubuntu.mirror.tudos.de. ubuntu.mirror.tudos.de has address 141.76.1.208 ubuntu.mirror.tudos.de has address 141.30.62.22 ubuntu.mirror.tudos.de has address 141.76.1.204 ubuntu.mirror.tudos.de has address 141.30.62.23 ubuntu.mirror.tudos.de has address 141.76.1.200 root at discourse:~# No v6 address, so no updates. (Sure, I could have used uk.archive.ubuntu.com, which is available on v6 as well, but you will not always find a replacement URL that works on v6-only.) So that VM now does have an RFC1918 IPv4 address that's NATed on the Hypervisor ... To make a long story short: if you want to start a new internet service, you need connectivity to the legacy, IPv4-based, Internet. There are v4-only customers out there (e. g. business customers of Unitymedia (Liberty Global's German branch) only get one public v4 IP for NAT and cannot get v6 at all), and this is not going to change anytime soon, as you can see in your area as well. Actually, even some public clouds didn't provide v6 until recently. And, in some cases, at least for parts of their fleet confirmed they never will. The question at hand is: how long should the RIPE Community keep the door open? IPv4 is already restricted to new LIRs, and LIRs are supposed to hand that space down to their customers. If your business needs new IPv4 space, these days you have to become a new LIR, which as of now costs you a 2000 EUR signup fee and a 1400 EUR yearly fee. Currently you'll get a /22, i. e. 4 /24, with no questions asked (and an /29 of v6, IIRC). And a(nother) vote in the RIPE NCC assembly ... 2017-03 would change this to "you get a /24" per new LIR, effectively raising the cost of an /24 from ~85 EUR/month to ~173 EUR/month (assuming 36 months to "earn back" the signup fee), but not enforcing IPv6 deployment in any way. If we, as the RIPE Community, really want to preserve the scarse IPv4 ressources for "new entrants" to be able to deploy v6, more is needed than just shrinking the assignment: IPv4 *is* done. The only use case RIPE NCC should assign new IPv4 address space for is for documented and needed v6 transitions services ? and it has to prohibit transfers on this space, as any transfer would nullify the initial use case anyway, therefore opening the path to reclaim the assignment. And to make this setup last even longer, only a /28 should be assigned, as you don't need 256 IPs for a 6-to-4-gateway service anyway (do you, if so, why?). Get this aligned with ARIN and the other RIRs, it should be quite possible to get a bunch of /somethings routed at /28 level. But 2017-03 simply raises the cost per /24, without enforcing v6 deployment in any way. It therefore shouldn't pass. Regards, -kai From randy at psg.com Sun Sep 24 04:55:21 2017 From: randy at psg.com (Randy Bush) Date: Sun, 24 Sep 2017 11:55:21 +0900 Subject: [address-policy-wg] 2017-03, New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <8F620286-4C3F-443E-82FC-56F2F13F1CF0@steffann.nl> References: <7a584263-a004-8aaf-544a-108b30001581@gmail.com> <59C6C6E8.1000407@foobar.org> <8F620286-4C3F-443E-82FC-56F2F13F1CF0@steffann.nl> Message-ID: > In both scenarios relying on only IPv4 is insanity, it's a business decision, and probably has many factors behind it. you and i might think it unwise, but 'insanity' is a bit in the weeds. > They are beyond help not at all. the vendors are more than happy to sell them CGNs, and other NATs of many flavors. i just don't like the result. but, as i said, we have demonstrated time and again that we can not seriously affect the tragically slow deployment of ipv6. so i do not make decisions based on changing that. >> P.S : This time I use my v6 smtp server even though at home I cannot >> still use a v6 prefix ;) same here, darn it. welcome to NTT B-Flets land. randy From randy at psg.com Sun Sep 24 04:58:19 2017 From: randy at psg.com (Randy Bush) Date: Sun, 24 Sep 2017 11:58:19 +0900 Subject: [address-policy-wg] 2017-03, New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <08fd41e5-7bb0-539b-3d49-4c2b05e2042d@uu.org> References: <7a584263-a004-8aaf-544a-108b30001581@gmail.com> <59C6C6E8.1000407@foobar.org> <08fd41e5-7bb0-539b-3d49-4c2b05e2042d@uu.org> Message-ID: [ generally good analysis ] > The only use case RIPE NCC should assign new IPv4 address space for is > for documented and needed v6 transitions services do not make rules you can not measure or enforce. it weakens the credibility of the rest of the structure. randy From randy at psg.com Sun Sep 24 05:03:59 2017 From: randy at psg.com (Randy Bush) Date: Sun, 24 Sep 2017 12:03:59 +0900 Subject: [address-policy-wg] 2017-03, New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <8F620286-4C3F-443E-82FC-56F2F13F1CF0@steffann.nl> References: <7a584263-a004-8aaf-544a-108b30001581@gmail.com> <59C6C6E8.1000407@foobar.org> <8F620286-4C3F-443E-82FC-56F2F13F1CF0@steffann.nl> Message-ID: > P.S : This time I use my v6 smtp server even though at home I cannot > still use a v6 prefix ;) interesting to see the whole trail. Received: from psg.com ([2001:418:1::62]) by ran.psg.com with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1dvx51-000885-77 for randy at ran.psg.com; Sun, 24 Sep 2017 02:55:39 +0000 Received: from [2001:67c:2e8:11::c100:1372] (helo=mahimahi.ripe.net) by psg.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89 (FreeBSD)) (envelope-from ) id 1dvx50-000K7L-8w for randy at psg.com; Sun, 24 Sep 2017 02:55:38 +0000 Received: from titi.ripe.net ([193.0.23.11]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1dvx4r-000Am2-6a; Sun, 24 Sep 2017 04:55:31 +0200 Received: from chouchou.ripe.net ([193.0.19.37]) by titi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1dvx4q-0008Iz-TD; Sun, 24 Sep 2017 04:55:28 +0200 Received: from localhost.localdomain ([127.0.0.1] helo=chouchou.ripe.net) by chouchou.ripe.net with esmtp (Exim 4.84_2) (envelope-from ) id 1dvx4q-0002yO-O6; Sun, 24 Sep 2017 04:55:28 +0200 Received: from mahimahi.ripe.net ([2001:67c:2e8:11::c100:1372]) by chouchou.ripe.net with esmtp (Exim 4.84_2) (envelope-from ) id 1dvx4p-0002yI-Oa for address-policy-wg at lists.ripe.net; Sun, 24 Sep 2017 04:55:27 +0200 Received: from ran.psg.com ([2001:418:8006::18]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dvx4o-000Alk-Lk for address-policy-wg at ripe.net; Sun, 24 Sep 2017 04:55:27 +0200 Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1dvx4l-00087z-Nh; Sun, 24 Sep 2017 02:55:24 +0000 as i said, thanks to NTT i have no ipv6 at home. but it goes v6 as soon as it hits my outbound smtp server, arrives at the ncc over ipv6, bounces around within the ncc over ipv4, and then exits the ncc over ipv6 randy From danny at danysek.cz Sun Sep 24 09:31:53 2017 From: danny at danysek.cz (Daniel Suchy) Date: Sun, 24 Sep 2017 09:31:53 +0200 Subject: [address-policy-wg] 2017-03, New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <08fd41e5-7bb0-539b-3d49-4c2b05e2042d@uu.org> References: <7a584263-a004-8aaf-544a-108b30001581@gmail.com> <59C6C6E8.1000407@foobar.org> <08fd41e5-7bb0-539b-3d49-4c2b05e2042d@uu.org> Message-ID: Hi, you still pay only *membership* fee. It's not a per-IP cost, even if it can look like that. Old resource holders pays similar fee independently from number of IP addresses they hold. One of goals is *conservation*, and initial assignment of /24 helps with that - and not each new LIR really needs /22. There're lot of organisationss having single /24 (old PI allocations) from the past and they're still happy with that. These were allocated to end users, are routed and also nobody concerned about routing table size. Since posibility of PI alocations was ceased, new organisations have to become "full LIR" - and then you receive /22, automatically - even you don't need it. We're simply wasting limited addres space here - just because something "simplified" and "automated". Alocating /24 to new LIRs with keeping possibility to earn up to /22 (in case of documented need) is solution in my eyes. Old policies worked perfectly with such system for years - without problems, RIPE NCC has deep experience with that. Administrative overhead will be minimal, as RIPE NCC is also running assisted registry checks even for quite new LIRs (so first iteration of ARC can be done during new request). With regards, Daniel On 09/24/2017 04:38 AM, Kai 'wusel' Siering wrote: > 2017-03 would change this to "you get a /24" per new LIR, effectively raising the cost of an /24 from ~85 EUR/month to ~173 EUR/month (assuming 36 months to "earn back" the signup fee), but not enforcing IPv6 deployment in any way. > > If we, as the RIPE Community, really want to preserve the scarse IPv4 ressources for "new entrants" to be able to deploy v6, more is needed than just shrinking the assignment: IPv4 *is* done. > The only use case RIPE NCC should assign new IPv4 address space for is for documented and needed v6 transitions services ? and it has to prohibit transfers on this space, as any transfer would nullify the initial use case anyway, therefore opening the path to reclaim the assignment. And to make this setup last even longer, only a /28 should be assigned, as you don't need 256 IPs for a 6-to-4-gateway service anyway (do you, if so, why?). Get this aligned with ARIN and the other RIRs, it should be quite possible to get a bunch of /somethings routed at /28 level. > > But 2017-03 simply raises the cost per /24, without enforcing v6 deployment in any way. It therefore shouldn't pass. From rgori at wirem.net Sun Sep 24 11:48:41 2017 From: rgori at wirem.net (Riccardo Gori) Date: Sun, 24 Sep 2017 11:48:41 +0200 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: Message-ID: Dear all, I started as an ISP early 2015 and I still consider myself a new entrant. In the last 2 years I heard about a couple of time "no more IPv4 policies let's go over and think how to fix/help IPv6 rate adoption" but today we are still here complaining what's the best way to last longer with the agony. For Ipv6 RIPE NCC is doing its best with training and is really appreciated and I learned here that we tend to not mix IPv4/6 policies but I really expected incentives from the cummunity not obstacles. The "IPv6 Requirement for Receiving Space from the Final /8" was abandoned 23/10/2014 by the adoption of 2014-04 proposal while this 2017-03 proposal aims to last as longer as possible with IPv4. Looks to me that we are trying to save future generation from ice melting saving oil tanks instead of working on research and incentives to clean energies. I don't see even any reason to save more address space than the current policies does 'casue we have "trasfert policies" for almost any kind of IP resource and if there are some restrictions on new allocation there are more flexible for legacy space. Today you can simply choose to go RIPE or market as your feeling to get IPv4/6 if needed. My small router deals today with more than 2.5 million routes (2 full routing tables and some IX) and it really takes time to backup and even routing performance are affected by volume of routes. I think we should propote IPv6 for route aggregation ability. I see this policy as: - an obstacle to IPv6 - a clear side effect of market price rise on IPv4 - a disincentive to route aggregation That's why I oppose this policy kind regards Riccardo -- Riccardo Gori From info at servereasy.it Sun Sep 24 12:09:24 2017 From: info at servereasy.it (Servereasy) Date: Sun, 24 Sep 2017 12:09:24 +0200 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: Message-ID: <9e8f5a48-9e85-760f-d3d2-039f3850e4a6@servereasy.it> I totally agree with Riccardo, I oppose to this policy as it could cause visibility/performance issues as lot of ISPs are filtering /24s. In my opinion, this problem will never be solved unless using IPv4 will become financially unattractive: I can't see why LIRs owning tons of /16s should start using IPv6. To me, an equal and fair solution would be to make RIPE annual fee dependant on currently owned IPv4 allocations. It's pretty obvious that the majority of LIRs owns more than just a /22 and won't never approve that. Br Il 24/09/2017 11:48, Riccardo Gori ha scritto: > Dear all, > > I started as an ISP early 2015 and I still consider myself a new > entrant. In the last 2 years I heard about a couple of time "no more > IPv4 policies let's go over and think how to fix/help IPv6 rate > adoption" but today we are still here complaining what's the best way > to last longer with the agony. > > For Ipv6 RIPE NCC is doing its best with training and is really > appreciated and I learned here that we tend to not mix IPv4/6 policies > but I really expected incentives from the cummunity not obstacles. The > "IPv6 Requirement for Receiving Space from the Final /8" was abandoned > 23/10/2014 by the adoption of 2014-04 proposal while this 2017-03 > proposal aims to last as longer as possible with IPv4. Looks to me > that we are trying to save future generation from ice melting saving > oil tanks instead of working on research and incentives to clean > energies. > > I don't see even any reason to save more address space than the > current policies does 'casue we have "trasfert policies" for almost > any kind of IP resource and if there are some restrictions on new > allocation there are more flexible for legacy space. Today you can > simply choose to go RIPE or market as your feeling to get IPv4/6 if > needed. > > My small router deals today with more than 2.5 million routes (2 full > routing tables and some IX) and it really takes time to backup and > even routing performance are affected by volume of routes. I think we > should propote IPv6 for route aggregation ability. > > I see this policy as: > - an obstacle to IPv6 > - a clear side effect of market price rise on IPv4 > - a disincentive to route aggregation > > That's why I oppose this policy > kind regards > Riccardo From danny at danysek.cz Sun Sep 24 12:34:49 2017 From: danny at danysek.cz (Daniel Suchy) Date: Sun, 24 Sep 2017 12:34:49 +0200 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <9e8f5a48-9e85-760f-d3d2-039f3850e4a6@servereasy.it> References: <9e8f5a48-9e85-760f-d3d2-039f3850e4a6@servereasy.it> Message-ID: <8f4f1c94-2e41-aecf-dbd0-b4501535e7ad@danysek.cz> I don't think. Even DNS operators (root and TLD) are normally using /24 for their anycast nodes - and DNS reachability is *critical* for internet operation. Also other services - like CDNs for Google, Facebook etc are using /24 - and yes, those *large* service providers are fragmenting their prefixes and increasing size of DFZ. In the past, /24 was *normally* used for PI allocations even in RIPE NCC region, and they're still active... If someone filters prefixes due to limited HW resources in his own equipmnet, he *always* has default route pointing to someone with full (unfiltered) BGP view, where final routing decision is made. It's a must, running network filtering /24 without default route pointing out to upstream is technical suicide. - Daniel On 09/24/2017 12:09 PM, Servereasy wrote: > as it could cause visibility/performance issues as lot of ISPs are filtering /24s. From cfriacas at fccn.pt Sun Sep 24 13:48:33 2017 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Sun, 24 Sep 2017 12:48:33 +0100 (WEST) Subject: [address-policy-wg] 2017-03, New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <59C6E0E9.2000501@foobar.org> References: <7a584263-a004-8aaf-544a-108b30001581@gmail.com> <59C6C6E8.1000407@foobar.org> <59C6E0E9.2000501@foobar.org> Message-ID: Hi, On Sat, 23 Sep 2017, Nick Hilliard wrote: > Willy MANGA wrote: >> So again, why do they rely on v4 (only) ? I really want to understand >> hurdles on european continent. >> >> I hope this time, it will be clearer :) > > same reason as in africa: for most organisations it's too much work with > too little return. Or in any other part of the world... > Many humans will only react after a crisis hits, even if the cost of > that is higher overall. Exactly! Cheers, Carlos > Nick > > From cfriacas at fccn.pt Sun Sep 24 15:09:11 2017 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Sun, 24 Sep 2017 14:09:11 +0100 (WEST) Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: Message-ID: Hi Riccardo, All, Thanks for your input. Please see inline. On Sun, 24 Sep 2017, Riccardo Gori wrote: > Dear all, > > I started as an ISP early 2015 and I still consider myself a new entrant. That's not my definition for "new entrant". Strictly i consider a new entrant as an organization which doesn't own any IPv4 or IPv6 address space. Loosely, it can be a new LIR (before getting its /22 and an IPv6 block under current policy)... But, luckly the community approved a policy for the last /8 long before 2015. If that didn't happen, your only solution would have been to rely on the market. > In > the last 2 years I heard about a couple of time "no more IPv4 policies let's > go over and think how to fix/help IPv6 rate adoption" but today we are still > here complaining what's the best way to last longer with the agony. Is "no more IPv4 policies" written in stone somewhere? :-) Fix IPv6 rate adoption by policy? Let's call our countries' telecom regulators, and ask for a policy that prohibits IPv4 usage from day X onwards? -- i don't think so........... > For Ipv6 RIPE NCC is doing its best with training and is really appreciated +1 on that! > and I learned here that we tend to not mix IPv4/6 policies but I really > expected incentives from the cummunity not obstacles. The "IPv6 Requirement > for Receiving Space from the Final /8" was abandoned 23/10/2014 by the > adoption of 2014-04 proposal Looking back now, was that a good decision...? > while this 2017-03 proposal aims to last as > longer as possible with IPv4. Should we tweak it, and make it more "stricter", in a way the address space is (automatically?) returned if it's not being used in v4/v6 translation mechanisms...? (and do we have means to check that?) > Looks to me that we are trying to save future > generation from ice melting saving oil tanks instead of working on research > and incentives to clean energies. Incentives cost money -- taxpayers' or consumers' money (or both!) > I don't see even any reason to save more address space than the current > policies does 'casue we have "trasfert policies" Transfers of last /8 slices are still allowed after 24 months -- should that possibility end...? (2017-03 v1.0 doesn't address transfers) > for almost any kind of IP > resource and if there are some restrictions on new allocation there are more > flexible for legacy space. The RIPE community (through the NCC) only provides services to legacy space holders (and there was a proprosal for that... 2012-07). The RIPE community is not able to design policies regarding address space which was distributed before the NCC's creation. > Today you can simply choose to go RIPE or market > as your feeling to get IPv4/6 if needed. If the choice is going to the "market" (and if you are in strict sense a new entrant), the "market" will not advocate you should use/deploy IPv6. On the other hand, if the choice is becoming a LIR, you will get that... :-) > My small router deals today with more than 2.5 million routes (2 full routing > tables and some IX) and it really takes time to backup and even routing > performance are affected by volume of routes. I think we should propote IPv6 > for route aggregation ability. There is also de-aggregation in IPv6-land. :-( (http://www.cidr-report.org/v6/as2.0/) People will mess up routing as the rest of the world lets them... > I see this policy as: > - an obstacle to IPv6 That was not the goal. The goal was to extend v4 availability for some more time, thus making life easier for IPv6 deployments that will still need to talk with the v4 world. > - a clear side effect of market price rise on IPv4 This proposal is not about the "market". a /24 can cost X, Y or Z over time. The only way we can keep "affordability" for new entrants is by defining what they get from the NCC, not from any 3rd party. > - a disincentive to route aggregation I don't agree. /22s (and bigger chunks) are already being announced as /24s. What we consider is that keeping the "affordability" for new entrants is a bigger priority than keeping the DFZ on 683k (today) instead of 725k, 750k or even 800k routes. I know 800k routes looks insane, but two years ago 683k would have been equally insane :-)) ps: On 24-09-2015 (two years ago), 572876 routes https://web.archive.org/web/20150924225101/https://www.cidr-report.org/as2.0/ Thanks! Best Regards, Carlos Fria?as > That's why I oppose this policy > kind regards > Riccardo > > -- > Riccardo Gori > From arash_mpc at parsun.com Sun Sep 24 18:31:49 2017 From: arash_mpc at parsun.com (Arash Naderpour) Date: Mon, 25 Sep 2017 02:31:49 +1000 Subject: [address-policy-wg] 2017-03, New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: <7a584263-a004-8aaf-544a-108b30001581@gmail.com> <59C6C6E8.1000407@foobar.org> <08fd41e5-7bb0-539b-3d49-4c2b05e2042d@uu.org> Message-ID: <000e01d33552$a28e9500$e7abbf00$@parsun.com> Hi Daniel, >you still pay only *membership* fee. It's not a per-IP cost, even if it can look like that. Old resource holders pays similar fee independently from number of IP addresses they hold. RIPE NCC members can change this charging scheme, right? It was not like this always... > One of goals is *conservation*, and initial assignment of /24 helps with that - and not each new LIR really needs /22. There're lot of organisationss having single /24 (old PI allocations) from the past and they're still happy with that. These were allocated to end users, are routed and also nobody concerned about routing table size. Since posibility of PI alocations was ceased, new organisations have to become "full LIR" - and then you receive /22, automatically - even you don't need it. We're simply wasting limited addres space here - just because something "simplified" and "automated". An org will not be limited to /24 even with this proposal; they can open additional LIRs to get more. Or register a new business if RIPE NCC bans multi LIR again. It is not easy to say that we are wasting limited address space by allocating /22, the ones need less than an /22 can transfer their free blocks to others who are in need (even new entrants) after two years or lease them immediately. Maybe there are some LIRs don?t fully utilize their /22 as soon as they receive the allocation, but what about the ones got their allocations before last /8 policy, are they all fully used? The actual wasting was done somewhere else years ago, and nobody cares about that now. Regards, Arash From gert at space.net Sun Sep 24 18:49:38 2017 From: gert at space.net (Gert Doering) Date: Sun, 24 Sep 2017 18:49:38 +0200 Subject: [address-policy-wg] 2017-03, New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <7a584263-a004-8aaf-544a-108b30001581@gmail.com> References: <7a584263-a004-8aaf-544a-108b30001581@gmail.com> Message-ID: <20170924164938.GQ45648@Space.Net> Hi, On Sat, Sep 23, 2017 at 08:54:01PM +0100, Willy MANGA wrote: > Le 22/09/2017 ? 08:47, address-policy-wg-request at ripe.net a ?crit?: > > [...] > > I'm working around IPv6 since 2001. Anna and Randy probably since before > > that. We have deployed IPv6. It didn't enable us to completely get rid of > > IPv4 within our networks. That also didn't solve any issue for 3rd party > > networks -- they all still need IPv4 addresses. > > being a newbie here can you please explain briefly why, as of today , > these people really need IPv4 addresses ? Or at least why they cannot > start a transition process towards IPv6? The problem is not "the new people" - the problem is "all the other people". What good is having an all-ipv6-network when your users will not be able to shop at, say, www.amazon.de, because that content site is IPv4-only? So you need to have some sort of IPv6-to-IPv4 translator device - and that one needs a few IPv4 adresses. And vice versa, if you host content, you'll need to be able to serve your content to those ISPs like Telefonica that have "no plans to implement IPv6, we can do this all with Carrier Grade NAT44!" [they did a press release to that extent, a few years ago...] - so, a few IPv4 addresses to tack on your load balancers, so they can server IPv6-only content to IPv4-only users... This is the real dilemma here: new entrants on the market feel the pain of old entrants not moving forward. Of course for the old entrants, this is a highly convenient way to keep their costs down, and everyone else's costs high ("externalize", as it has been said before) Gert Doering -- concerned Internet user -- 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: 833 bytes Desc: not available URL: From ximaera at gmail.com Sun Sep 24 19:38:59 2017 From: ximaera at gmail.com (Artyom Gavrichenkov) Date: Sun, 24 Sep 2017 20:38:59 +0300 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: <59C3C608.8050009@foobar.org> Message-ID: How is this related to my point (assuming this was a reply to my message in the first place)? | Artyom Gavrichenkov | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191 | mailto: ximaera at gmail.com | fb: ximaera | telegram: xima_era | skype: xima_era | tel. no: +7 916 515 49 58 On Fri, Sep 22, 2017 at 10:18 AM, Randy Bush wrote: > a bit of history for those with short term vision > > 1995, and large providers were running out of ram to hold the table. > sprint was the closest to the edge and falling over; but others were > not far behind and could smell the coffee. these were the days > where we all intimately knew each others' networks. > > nobody's management was gonna pay to upgrade hundreds of routers. > sean had to filter to keep from crashing. others, such as asp and > i, were also filtering, as much to keep the table down as to protect > from idiots such as vinnie from killing us (7007 incident). > > so the providers who were concerned and the rirs met at the danvers > ietf and agreed to only let /19s and shorter, and swamp space /24s, > through if the rirs would please not allocate longer prefixes for a > couple of years until routers could be upgraded. rfc 2050 was the > result. > > eventually, like six yesrs later, customers complained enough that > the filters had to be removed. when a big customer or two wanted to > get to someone with a /24 in old B space, the filters fell. > business wins. > > when v4 runout forces folk to put /28s in frnt of nats, the folk with > shiny shoes will have a little chat with senior leadership, and they'll > cough up the bucks to hold the routes. history repeats. > > like the ethernet mfrs tell us that we need to use 4g, 40g, ... instead > of 10g, 100g, 1tb, ... life adds zeros. > > randy From cfriacas at fccn.pt Sun Sep 24 20:33:15 2017 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Sun, 24 Sep 2017 19:33:15 +0100 (WEST) Subject: [address-policy-wg] 2017-03, New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <000e01d33552$a28e9500$e7abbf00$@parsun.com> References: <7a584263-a004-8aaf-544a-108b30001581@gmail.com> <59C6C6E8.1000407@foobar.org> <08fd41e5-7bb0-539b-3d49-4c2b05e2042d@uu.org> <000e01d33552$a28e9500$e7abbf00$@parsun.com> Message-ID: On Mon, 25 Sep 2017, Arash Naderpour wrote: > Hi Daniel, Hi, >> you still pay only *membership* fee. It's not a per-IP cost, even if it can look like that. Old resource holders pays similar fee independently from number of IP addresses they hold. > > RIPE NCC members can change this charging scheme, right? It was not like this always... You are correct: RIPE NCC members. This group is not a perfect match with the community that discusses and builds up policies :-) >> One of goals is *conservation*, and initial assignment of /24 helps with that - and not each new LIR really needs /22. There're lot of organisationss having single /24 (old PI allocations) from the past and they're still happy with that. These were allocated to end users, are routed and also nobody concerned about routing table size. Since posibility of PI alocations was ceased, new organisations have to become "full LIR" - and then you receive /22, automatically - even you don't need it. We're simply wasting limited addres space here - just because something "simplified" and "automated". > > An org will not be limited to /24 even with this proposal; they can > open additional LIRs to get more. Yes, 2017-03 v1.0 doesn't try to limit that -- if i understood correctly, some people disagree, and think it should. > Or register a new business if RIPE NCC bans multi LIR again. I guess only the RIPE NCC GA can do that, not RIPE NCC itself. > It is not easy to say that we are wasting limited address space by > allocating /22, the ones need less than an /22 can transfer their free > blocks to others who are in need (even new entrants) in need, or not (if they are only trying to stockpile for later...) > after two years or lease them immediately. Yes... that's current policy, and 2017-03 doesn't touch that. > Maybe there are some LIRs don?t fully utilize their /22 as soon as > they receive the allocation, but what about the ones got their > allocations before last /8 policy, are they all fully used? Of course not. > The actual wasting was done somewhere else years ago, and nobody cares > about that now. There is also the issue with "refurbished" address space... apart from the issue that IPv4 address space now has value, so creating a new rule/policy to "extract" it frow its current owners is quite inimaginable... :-) Regards, Carlos Fria?as > Regards, > > Arash From sander at steffann.nl Sun Sep 24 20:38:20 2017 From: sander at steffann.nl (Sander Steffann) Date: Sun, 24 Sep 2017 20:38:20 +0200 Subject: [address-policy-wg] 2017-03, New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: <7a584263-a004-8aaf-544a-108b30001581@gmail.com> <59C6C6E8.1000407@foobar.org> <8F620286-4C3F-443E-82FC-56F2F13F1CF0@steffann.nl> Message-ID: <4832F09A-560A-4E5B-B08A-018E3A5E0ABB@steffann.nl> Hi, > Op 24 sep. 2017, om 04:55 heeft Randy Bush het volgende geschreven: > >> They are beyond help > > not at all. the vendors are more than happy to sell them CGNs, and > other NATs of many flavors. Sorry, I should have specified "from a IPv4 allocation policy point of view" :) Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP URL: From randy at psg.com Sun Sep 24 20:42:14 2017 From: randy at psg.com (Randy Bush) Date: Mon, 25 Sep 2017 03:42:14 +0900 Subject: [address-policy-wg] 2017-03, New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <4832F09A-560A-4E5B-B08A-018E3A5E0ABB@steffann.nl> References: <7a584263-a004-8aaf-544a-108b30001581@gmail.com> <59C6C6E8.1000407@foobar.org> <8F620286-4C3F-443E-82FC-56F2F13F1CF0@steffann.nl> <4832F09A-560A-4E5B-B08A-018E3A5E0ABB@steffann.nl> Message-ID: >>> They are beyond help >> >> not at all. the vendors are more than happy to sell them CGNs, and >> other NATs of many flavors. > > Sorry, I should have specified "from a IPv4 allocation policy point of > view" :) sorry. but having spent blood and tears on ipv6 deployment for over 20 years, watching ipv6 zealots create a massive NAT market really really hurts. randy From sander at steffann.nl Sun Sep 24 20:44:21 2017 From: sander at steffann.nl (Sander Steffann) Date: Sun, 24 Sep 2017 20:44:21 +0200 Subject: [address-policy-wg] 2017-03, New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: <7a584263-a004-8aaf-544a-108b30001581@gmail.com> <59C6C6E8.1000407@foobar.org> <8F620286-4C3F-443E-82FC-56F2F13F1CF0@steffann.nl> <4832F09A-560A-4E5B-B08A-018E3A5E0ABB@steffann.nl> Message-ID: <82ECBBBC-53BC-4B02-9D61-5A148FEFA59E@steffann.nl> Hi, > Op 24 sep. 2017, om 20:42 heeft Randy Bush het volgende geschreven: > >>>> They are beyond help >>> >>> not at all. the vendors are more than happy to sell them CGNs, and >>> other NATs of many flavors. >> >> Sorry, I should have specified "from a IPv4 allocation policy point of >> view" :) > > sorry. but having spent blood and tears on ipv6 deployment for over 20 > years, watching ipv6 zealots create a massive NAT market really really > hurts. Indeed :( Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP URL: From kuenzler at init7.net Sun Sep 24 21:07:09 2017 From: kuenzler at init7.net (Fredy Kuenzler) Date: Sun, 24 Sep 2017 21:07:09 +0200 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: Message-ID: Dear all, pros and cons have been mentioned, I don't want to repeat things but I want to express opposition against this new policy proposal. Best regards, Fredy K?nzler Init7 On 21.09.2017 13:43, Marco Schmidt wrote: > Dear colleagues, > > A new RIPE Policy proposal, 2017-03, "Reducing Initial IPv4 > Allocation, aiming to preserve a minimum of IPv4 space", is now > available for discussion. > > The goal of this proposal is to reduce the IPv4 allocations made by > the RIPE NCC to a /24 (currently a /22) and only to LIRs that have > not received an IPv4 allocation directly from the RIPE NCC before. > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2017-03/ > > As per the RIPE Policy Development Process (PDP), the purpose of this > four-week Discussion Phase is to discuss the proposal and provide > feedback to the proposer. > > At the end of the Discussion Phase, the proposer, with the agreement > of the RIPE Working Group Chairs, decides how to proceed with the > proposal. > > We encourage you to review this proposal and send your comments to > before 20 October 2017. > > Kind regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > -- Fredy Kuenzler --------------------- Fiber7. No Limits. https://www.fiber7.ch --------------------- Init7 (Switzerland) Ltd. AS13030 Technoparkstrasse 5 CH-8406 Winterthur Skype: flyingpotato Phone: +41 44 315 4400 Fax: +41 44 315 4401 Twitter: @init7 / @kuenzler http://www.init7.net/ From wusel+ml at uu.org Mon Sep 25 01:01:50 2017 From: wusel+ml at uu.org (Kai 'wusel' Siering) Date: Mon, 25 Sep 2017 01:01:50 +0200 Subject: [address-policy-wg] 2017-03, New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: <7a584263-a004-8aaf-544a-108b30001581@gmail.com> <59C6C6E8.1000407@foobar.org> <08fd41e5-7bb0-539b-3d49-4c2b05e2042d@uu.org> Message-ID: Hi, am 24.09.2017 um 04:58 schrieb Randy Bush: > >> The only use case RIPE NCC should assign new IPv4 address space for is >> for documented and needed v6 transitions services > do not make rules you can not measure or enforce. it weakens the > credibility of the rest of the structure. It's quote common that you need to hand in a kind-of detailed network plan for larger deployments. As part of a revised last /8 policy, a detailed plan for using the requested (not: granted because you're a new LIR) v4 space for transition services can be requested, including evidence for it's deployment within 12 weeks. Yes, "evidence" can be faked. Does faking information currently serves as a breach of contractual obligations by the LIR, opening LIR termination? If not, there's some homework to do. Handing out, say, /28 instead of /24 would spoil this space for any trading. Yes, the route: needs to be on /24 level, but by having a route: entry of the /24 on AS3333 (or, maybe better, some designated "last /8 control ASN") means no other route: entry can be made without active involvement of RIPE NCC. This can be tracked, and the routing AS changes limited to 1 within 24 months. Usage beyond the assigned /28 boundary could be checked as well (RIPE ATLAS or a bunch of AWS instances, fired up randomly). I don't say it's easy. I don't say I like the idea. But I think it's doable and that an upcoming strict "v4 for v6 deployments only" policy is enforcable. The argument pro 2017-03 is "we need to conserve v4 space for those that come late to the show (in 3 to x0 years) and need to connect to github.com, amazon.com or other dinosaurs still on v4-only via transition techniques". Well, anything except an all-in to me is just for raising the per-/24 market price. Unless we poison the upcoming assignments ? (strictly?) no transfer, no generic use (yes, this is difficult to "measure and enforce"; nonetheless, a legal phrase of the intended use should be possible and added), assignment way below routing threshold, strong control by RIPE NCC ?, those *will* end up in the "v4 after market". In essence, RIPE NCC would "lease" the v4 addresses to these LIRs, not anymore "assign" them. Radical? Maybe. Necessary? To conserve as much v4 space for "anyone coming late", I think so. Regards, -kai From wusel+ml at uu.org Mon Sep 25 02:41:37 2017 From: wusel+ml at uu.org (Kai 'wusel' Siering) Date: Mon, 25 Sep 2017 02:41:37 +0200 Subject: [address-policy-wg] 2017-03, New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: <7a584263-a004-8aaf-544a-108b30001581@gmail.com> <59C6C6E8.1000407@foobar.org> <08fd41e5-7bb0-539b-3d49-4c2b05e2042d@uu.org> Message-ID: <08a43c4f-8d57-b6b5-8212-7a482458dd76@uu.org> Moin, am 24.09.2017 um 09:31 schrieb Daniel Suchy: > Hi, > > you still pay only *membership* fee. It's not a per-IP cost, even if it > can look like that. Old resource holders pays similar fee independently > from number of IP addresses they hold. Please don't get me started on that ... For the time being, assume I runa business and am a LIR already, and a customer who needs 2 /24 for his more-than-awesome service. Will I direct himto competitors that got /16s in the past, or will I opt for another LIR undercurrect policy, calculate that cost and present him with that bill? If all costs (another company, another LIR, etc.) are covered, why would I reject the deal? > One of goals is *conservation*, and initial assignment of /24 helps with > that - and not each new LIR really needs /22. There're lot of > organisationss having single /24 (old PI allocations) from the past and > they're still happy with that. These were allocated to end users, are > routed and also nobody concerned about routing table size. Oh, they did, back then. That's the whole PA vs. PI thing[1], starting somewhere around 194/8or back, in the early 1990s. The idea was to assign huge amounts of address space to an LIR in the expectation it would be routed coherently. Didn't work in 194/8 due to lack of contractual clearance, IIRC 195/8 was the first "safe to filter" prefix? PI space back then was supplied from another netblock (193/8?), so filtering could be applied easily. But sometime later, a generic /24 filter was applied, and that's where we are today, AFAIK. > Since posibility of PI alocations was ceased, new organisations have to > become "full LIR" - and then you receive /22, automatically - even you > don't need it. We're simply wasting limited addres space here - just > because something "simplified" and "automated". No.A LIR is supposed to hand out addresses to customers based on customer needs (and contractual obligations to RIPE NCC). Shelling out a once-in- your-lifetime /22 prefix just makes sense, if this is an "old-school" LIR. It would typically use a /24 (routing threshold) for itself (www, mx), and seek for customers for the remainding 3 /24. Even if the company's legal entity has no use for v4, v4 address space does have a finacial value these days, so failure to secure that could be a punishable offence. > Alocating /24 to new LIRs with keeping possibility to earn up to /22 (in > case of documented need) is solution in my eyes. As stated elsewhere:anyone will be able to present "documented need" for the /22 ... so this is a moot point. Regards, -kai [1] https://www.ripe.net/publications/docs/ripe-509#----pa-vs--pi-address-space From stefanp-l-address-policy-wg at cabal1.net Mon Sep 25 14:59:29 2017 From: stefanp-l-address-policy-wg at cabal1.net (Stefan Paletta) Date: Mon, 25 Sep 2017 14:59:29 +0200 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: <397fd725-0403-dca7-539e-1550faa5e0e3@danysek.cz> <99c23a41034545ebb5eef1c212ce128b@elisa.fi> <96B06EA5-F50E-4E91-B297-F6ABFE08E717@heanet.ie> Message-ID: <20170925125929.GA1431@venlafaxine.cabal1.net> On Sat, Sep 23, 2017 at 09:24:55AM +0900, Randy Bush wrote: > "I am planning to open my own internet company in 4 years; can you > please save some address space for me, 'til I finish high school?" How little space is effectively equal to no (non-aggregate) space at all? For some businesses, a /22 will be as useless as a /24. Who knowns what kinds of new businesses will be most affected by this in four years? IPv4 allocation having left behind the ?as needed? phase really makes it impossible to bet on RIR-provided IPv4 space for anything other than transition mechanisms. ?Stefan From malcolm at linx.net Mon Sep 25 16:02:45 2017 From: malcolm at linx.net (Malcolm Hutty) Date: Mon, 25 Sep 2017 15:02:45 +0100 Subject: [address-policy-wg] Agenda for APWG in Dubai (v1) In-Reply-To: <1950F473-CA08-42EA-8D02-66D65B6EA904@steffann.nl> References: <1950F473-CA08-42EA-8D02-66D65B6EA904@steffann.nl> Message-ID: <5b67c3f9-d302-a3e4-c38a-611b9598c465@linx.net> Dear WG Chairs, This is a request for a short agenda item for Dubai, or matter arising. I would like the WG to be aware of policy proposal 2017-02 that has been tabled in abuse-wg, for the RIPE NCC to conduct validation of abuse-cc. https://www.ripe.net/participate/policies/proposals/2017-02 No insult intended to abuse-wg, but it's not the most well attended WG. I'm not trying to start a debate in address-policy, but I think you could help by giving just a moment's "advertising" that this is going on, so that more people can consider whether this is a good idea. Malcolm. -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | http://publicaffairs.linx.net/ London Internet Exchange Ltd Monument Place, 24 Monument Street London EC3R 8AJ Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA From sander at steffann.nl Mon Sep 25 19:25:03 2017 From: sander at steffann.nl (Sander Steffann) Date: Mon, 25 Sep 2017 17:25:03 +0000 Subject: [address-policy-wg] Agenda for APWG in Dubai (v1) In-Reply-To: <5b67c3f9-d302-a3e4-c38a-611b9598c465@linx.net> References: <1950F473-CA08-42EA-8D02-66D65B6EA904@steffann.nl> <5b67c3f9-d302-a3e4-c38a-611b9598c465@linx.net> Message-ID: <291777AD-789C-4B17-BE2B-3D41DB453F0E@steffann.nl> Noted, we'll refer people to anti abuse when discussing open policy proposals. Marco: I assume this is already on your list, but please double check :) Cheers, Sander > Op 25 sep. 2017 om 14:02 heeft Malcolm Hutty het volgende geschreven: > > Dear WG Chairs, > > This is a request for a short agenda item for Dubai, or matter arising. > > I would like the WG to be aware of policy proposal 2017-02 that has been > tabled in abuse-wg, for the RIPE NCC to conduct validation of abuse-cc. > > https://www.ripe.net/participate/policies/proposals/2017-02 > > No insult intended to abuse-wg, but it's not the most well attended WG. > I'm not trying to start a debate in address-policy, but I think you > could help by giving just a moment's "advertising" that this is going > on, so that more people can consider whether this is a good idea. > > Malcolm. > -- > Malcolm Hutty | tel: +44 20 7645 3523 > Head of Public Affairs | Read the LINX Public Affairs blog > London Internet Exchange | http://publicaffairs.linx.net/ > > London Internet Exchange Ltd > Monument Place, 24 Monument Street London EC3R 8AJ > > Company Registered in England No. 3137929 > Trinity Court, Trinity Street, Peterborough PE1 1DA From mschmidt at ripe.net Tue Sep 26 08:55:55 2017 From: mschmidt at ripe.net (Marco Schmidt) Date: Tue, 26 Sep 2017 08:55:55 +0200 Subject: [address-policy-wg] Agenda for APWG in Dubai (v1) In-Reply-To: <291777AD-789C-4B17-BE2B-3D41DB453F0E@steffann.nl> References: <1950F473-CA08-42EA-8D02-66D65B6EA904@steffann.nl> <5b67c3f9-d302-a3e4-c38a-611b9598c465@linx.net> <291777AD-789C-4B17-BE2B-3D41DB453F0E@steffann.nl> Message-ID: Hello, Yes, I will mention 2017-02 in my update and will put extra emphasis on where and when this proposal will be discussed. Marco On 25/09/2017 19:25, Sander Steffann wrote: > Noted, we'll refer people to anti abuse when discussing open policy proposals. Marco: I assume this is already on your list, but please double check :) > > Cheers, > Sander > >> Op 25 sep. 2017 om 14:02 heeft Malcolm Hutty het volgende geschreven: >> >> Dear WG Chairs, >> >> This is a request for a short agenda item for Dubai, or matter arising. >> >> I would like the WG to be aware of policy proposal 2017-02 that has been >> tabled in abuse-wg, for the RIPE NCC to conduct validation of abuse-cc. >> >> https://www.ripe.net/participate/policies/proposals/2017-02 >> >> No insult intended to abuse-wg, but it's not the most well attended WG. >> I'm not trying to start a debate in address-policy, but I think you >> could help by giving just a moment's "advertising" that this is going >> on, so that more people can consider whether this is a good idea. >> >> Malcolm. >> -- >> Malcolm Hutty | tel: +44 20 7645 3523 >> Head of Public Affairs | Read the LINX Public Affairs blog >> London Internet Exchange | http://publicaffairs.linx.net/ >> >> London Internet Exchange Ltd >> Monument Place, 24 Monument Street London EC3R 8AJ >> >> Company Registered in England No. 3137929 >> Trinity Court, Trinity Street, Peterborough PE1 1DA > > From wilhelm at ripe.net Tue Sep 26 09:02:56 2017 From: wilhelm at ripe.net (Rene Wilhelm) Date: Tue, 26 Sep 2017 09:02:56 +0200 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: <397fd725-0403-dca7-539e-1550faa5e0e3@danysek.cz> <99c23a41034545ebb5eef1c212ce128b@elisa.fi> <05D277B2-6F95-43C4-BB7A-D690F134DAB3@heanet.ie> <20170922180427.GN11532@x27.adm.denic.de> Message-ID: <5890ad90-8bb4-3da9-dfdd-3d964d14ecb8@ripe.net> Hi Carlos, All, On 9/23/17 1:02 AM, Carlos Fria?as wrote: > [...] >> do we know how many LIRs eligible under the current policy have not >> yet asked for a final /22? >> >> -Peter > > > Thanks for that question! > > > Looking at the alloclist from today, and filtering for RegIDs, i can > count: 16354 > (hmmm... # on https://labs.ripe.net/statistics is 16825, seems i'm > mising something...) > > But anyway... the number of IPv4 /22s is 15391. From that number: > 195 in Sept/2012 after the runout date. > 595 in Q4/2012 (runout was in september) > 1854 in 2013 > 2441 in 2014 > 3178 in 2015 > 3258 in 2016 > 2429 in 2017, so far. > > So, 13950 /22s between Q4/2012 and today, hence i would say your > answer is around 2404 LIRs (16354-13950). > > > ps: Someone at the NCC might have looked deeply into this, or not. :-) We last looked at this in detail at the start of the year, when we reached the 15000 LIRs milestone.See the RIPElabs article at https://labs.ripe.net/Members/wilhelm/15-000-local-internet-registries Redoing that analysis today, I find 4075 LIRs which do not have a final /22 allocation.3598 of these were established before 14 Sep 2012. The average allocation rate in the last 1.5 years was 9.1 /22s per day. At this rate the original last /8 (185/8) will be fully allocated in about 9 months, in June 2018.The rest of the currently available IPv4 space would last until January 2021. Occasional reclaims and deregistrations of IPv4 space of the size we've seen in the recent past could postpone full runout with a few more months, until July 2021. Best regards, -- Rene From jan at go6.si Tue Sep 26 10:26:49 2017 From: jan at go6.si (Jan Zorz - Go6) Date: Tue, 26 Sep 2017 10:26:49 +0200 Subject: [address-policy-wg] 2017-03, New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <8F620286-4C3F-443E-82FC-56F2F13F1CF0@steffann.nl> References: <7a584263-a004-8aaf-544a-108b30001581@gmail.com> <59C6C6E8.1000407@foobar.org> <8F620286-4C3F-443E-82FC-56F2F13F1CF0@steffann.nl> Message-ID: On 24/09/2017 00:38, Sander Steffann wrote: > ...or change the /22 to /24 and keep giving newcomers a tiny bit of > addresses for a while longer (what is currently being proposed). Hey, A quick math what a /24 can give you if you use if for translation/transition purposes only (NAT64 or A+P like MAP-E/T) If you connect to your upstream with *their* IP addresses and not break your /24 into smaller bits and connect your NAT64 or A+P PRR box directly to that BGP router, use first usable address as a gateway, second address as an interface address for your translation/transition box, then you are left with 252 usable addresses for your purpose. That means 65.535 ports per address, giving you 16.514.820 usable ports. Usually sane people predicts between 700 and 1000 ports per user, and that gives you between 16.514 and 23.592 possible users that you can serve at the same time and connect them to legacy IPv4 world. Now everyone will have to figure out if that's enough or not. :) Cheers, Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3976 bytes Desc: S/MIME Cryptographic Signature URL: From cfriacas at fccn.pt Tue Sep 26 10:50:42 2017 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Tue, 26 Sep 2017 09:50:42 +0100 (WEST) Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <5890ad90-8bb4-3da9-dfdd-3d964d14ecb8@ripe.net> References: <397fd725-0403-dca7-539e-1550faa5e0e3@danysek.cz> <99c23a41034545ebb5eef1c212ce128b@elisa.fi> <05D277B2-6F95-43C4-BB7A-D690F134DAB3@heanet.ie> <20170922180427.GN11532@x27.adm.denic.de> <5890ad90-8bb4-3da9-dfdd-3d964d14ecb8@ripe.net> Message-ID: Rene, Much appreciated! The projected dates you mentioned are very useful! Best Regards, Carlos Fria?as On Tue, 26 Sep 2017, Rene Wilhelm wrote: > Hi Carlos, All, > > > On 9/23/17 1:02 AM, Carlos Fria?as wrote: >> [...] >>> do we know how many LIRs eligible under the current policy have not >>> yet asked for a final /22? >>> >>> -Peter >> >> >> Thanks for that question! >> >> >> Looking at the alloclist from today, and filtering for RegIDs, i can count: >> 16354 >> (hmmm... # on https://labs.ripe.net/statistics is 16825, seems i'm mising >> something...) >> >> But anyway... the number of IPv4 /22s is 15391. From that number: >> 195 in Sept/2012 after the runout date. >> 595 in Q4/2012 (runout was in september) >> 1854 in 2013 >> 2441 in 2014 >> 3178 in 2015 >> 3258 in 2016 >> 2429 in 2017, so far. >> >> So, 13950 /22s between Q4/2012 and today, hence i would say your answer is >> around 2404 LIRs (16354-13950). >> >> >> ps: Someone at the NCC might have looked deeply into this, or not. :-) > > We last looked at this in detail at the start of the year, when we > reached the 15000 LIRs milestone.See the RIPElabs article at > https://labs.ripe.net/Members/wilhelm/15-000-local-internet-registries > > Redoing that analysis today, I find 4075 LIRs which do not have a > final /22 allocation.3598 of these were established before 14 Sep 2012. > > The average allocation rate in the last 1.5 years was 9.1 /22s per day. > At this rate the original last /8 (185/8) will be fully allocated in > about 9 months, in June 2018.The rest of the currently available > IPv4 space would last until January 2021. Occasional reclaims and > deregistrations of IPv4 space of the size we've seen in the recent past > could postpone full runout with a few more months, until July 2021. > > Best regards, > > -- Rene > From d.baeza at tvt-datos.es Tue Sep 26 11:14:00 2017 From: d.baeza at tvt-datos.es (Daniel Baeza) Date: Tue, 26 Sep 2017 11:14:00 +0200 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: <397fd725-0403-dca7-539e-1550faa5e0e3@danysek.cz> <99c23a41034545ebb5eef1c212ce128b@elisa.fi> <05D277B2-6F95-43C4-BB7A-D690F134DAB3@heanet.ie> <20170922180427.GN11532@x27.adm.denic.de> <5890ad90-8bb4-3da9-dfdd-3d964d14ecb8@ripe.net> Message-ID: <1b938879-e953-9d56-5f8f-d40b58da8c9f@tvt-datos.es> Hi all, I oppose this proposal. 1) If the actual routing table grows very quick, with all new lirs publishing /24 will make it over 1M routes in no-time, making mandatory to change "old" but very good routers that only can have 1M routes. Yes, I know there are a lot of /24 (370k) but if we "force" to publish /24, as they dont have anything longer, will kill it. 2) As all we know, there are a VERY HUGE difference between pre-runout LIRS and post-runout LIRS in terms of address space and, if this proposal is approved the difference will become astronomic. The ones that a this moment have full /8's without use will have at least doubled the price of their IPs, making them more richs (in terms of address space/price per ip). Again, instead of looking for a way to recover all the unused space from old LIRs or legacy we try to push more and more in the new ones. Thats my two cents. Regards, -- Daniel From jan at go6.si Tue Sep 26 12:02:33 2017 From: jan at go6.si (Jan Zorz - Go6) Date: Tue, 26 Sep 2017 12:02:33 +0200 Subject: [address-policy-wg] 2017-03, New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: <7a584263-a004-8aaf-544a-108b30001581@gmail.com> <59C6C6E8.1000407@foobar.org> <8F620286-4C3F-443E-82FC-56F2F13F1CF0@steffann.nl> Message-ID: On 26/09/2017 10:26, Jan Zorz - Go6 wrote: > If you connect to your upstream with *their* IP addresses and not break > your /24 into smaller bits and connect your NAT64 or A+P PRR box > directly to that BGP router, use first usable address as a gateway, > second address as an interface address for your translation/transition > box, then you are left with 252 usable addresses for your purpose. That > means 65.535 ports per address, giving you 16.514.820 usable ports. > Usually sane people predicts between 700 and 1000 ports per user, and > that gives you between 16.514 and 23.592 possible users that you can > serve at the same time and connect them to legacy IPv4 world. > > Now everyone will have to figure out if that's enough or not. :) Forgot to add (thnx Raymond for reminding me of this issue)... While the above numbers may seem technically feasible, the hidden (or not so hidden) forces may want us to go different direction. Apparently there is a Belgium case: https://www.intgovforum.org/multilingual/content/igf-2017-ws-214-how-can-we-limit-the-negative-impact-of-carrier-grade-nat-technologies-and "The emphasis will be put on the Belgium case where the telecom regulator entered in a voluntary agreement with the 4 biggest ISPs in 2012 for them to limit the number of end-users behind each IPv4 addresses for security purposes (to help to identify end-users when served with a legal order in the framework of a criminal investigation). This led to the unintended positive consequence that major Belgium-based ISPs have made strategic business decision to transition quickly to IPv6. As a result, today Belgium has the highest IPv6 adoption rate in the world." I heard (and please correct me if I'm wrong) that in order to have a success in this legal investigations, there should not be more than 4 to 6 users behind each IP address. If this is really the case, then both /22 and /24 are more or less useless for any transition/translation technique if regulation will ever require this ratio as a requirement. :( It's a deep swamp and we created it as an industry with not keeping up properly and deploying IPv6... My question here is: Now what? Cheers, Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3976 bytes Desc: S/MIME Cryptographic Signature URL: From raymond.jetten at elisa.fi Tue Sep 26 12:23:18 2017 From: raymond.jetten at elisa.fi (Jetten Raymond) Date: Tue, 26 Sep 2017 10:23:18 +0000 Subject: [address-policy-wg] 2017-03, New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: <7a584263-a004-8aaf-544a-108b30001581@gmail.com> <59C6C6E8.1000407@foobar.org> <8F620286-4C3F-443E-82FC-56F2F13F1CF0@steffann.nl> Message-ID: <1321776e9c4949fd9a42fc181d8be0bc@elisa.fi> Hi Everyone, So to conclude* the whole thing, although we have not technically run out, we practically already have, and as you probably know by now, I still see no point in making another policy on this and still oppose this proposal. A /22 is not even enough, let alone a /24 to yet connect to the "dark ages of the IPv4 internet", not now and unfortunately not in the future either... * means I will not again explain my opinion after this on the same subject, it will remain unchanged. Rgds, Ray -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Jan Zorz - Go6 Sent: 26. syyskuuta 2017 13:03 To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2017-03, New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) On 26/09/2017 10:26, Jan Zorz - Go6 wrote: > If you connect to your upstream with *their* IP addresses and not break > your /24 into smaller bits and connect your NAT64 or A+P PRR box > directly to that BGP router, use first usable address as a gateway, > second address as an interface address for your translation/transition > box, then you are left with 252 usable addresses for your purpose. That > means 65.535 ports per address, giving you 16.514.820 usable ports. > Usually sane people predicts between 700 and 1000 ports per user, and > that gives you between 16.514 and 23.592 possible users that you can > serve at the same time and connect them to legacy IPv4 world. > > Now everyone will have to figure out if that's enough or not. :) Forgot to add (thnx Raymond for reminding me of this issue)... While the above numbers may seem technically feasible, the hidden (or not so hidden) forces may want us to go different direction. Apparently there is a Belgium case: https://www.intgovforum.org/multilingual/content/igf-2017-ws-214-how-can-we-limit-the-negative-impact-of-carrier-grade-nat-technologies-and "The emphasis will be put on the Belgium case where the telecom regulator entered in a voluntary agreement with the 4 biggest ISPs in 2012 for them to limit the number of end-users behind each IPv4 addresses for security purposes (to help to identify end-users when served with a legal order in the framework of a criminal investigation). This led to the unintended positive consequence that major Belgium-based ISPs have made strategic business decision to transition quickly to IPv6. As a result, today Belgium has the highest IPv6 adoption rate in the world." I heard (and please correct me if I'm wrong) that in order to have a success in this legal investigations, there should not be more than 4 to 6 users behind each IP address. If this is really the case, then both /22 and /24 are more or less useless for any transition/translation technique if regulation will ever require this ratio as a requirement. :( It's a deep swamp and we created it as an industry with not keeping up properly and deploying IPv6... My question here is: Now what? Cheers, Jan From ebais at a2b-internet.com Tue Sep 26 17:56:55 2017 From: ebais at a2b-internet.com (Erik Bais) Date: Tue, 26 Sep 2017 17:56:55 +0200 Subject: [address-policy-wg] 2017-03, New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: <7a584263-a004-8aaf-544a-108b30001581@gmail.com> <59C6C6E8.1000407@foobar.org> <8F620286-4C3F-443E-82FC-56F2F13F1CF0@steffann.nl> Message-ID: <011501d336e0$13923700$3ab6a500$@a2b-internet.com> > Now everyone will have to figure out if that's enough or not. :) That is clearly not enough... you are asking the obvious here Jan... ;-) Erik -----Oorspronkelijk bericht----- Van: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] Namens Jan Zorz - Go6 Verzonden: dinsdag 26 september 2017 10:27 Aan: address-policy-wg at ripe.net Onderwerp: Re: [address-policy-wg] 2017-03, New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) On 24/09/2017 00:38, Sander Steffann wrote: > ...or change the /22 to /24 and keep giving newcomers a tiny bit of > addresses for a while longer (what is currently being proposed). Hey, A quick math what a /24 can give you if you use if for translation/transition purposes only (NAT64 or A+P like MAP-E/T) If you connect to your upstream with *their* IP addresses and not break your /24 into smaller bits and connect your NAT64 or A+P PRR box directly to that BGP router, use first usable address as a gateway, second address as an interface address for your translation/transition box, then you are left with 252 usable addresses for your purpose. That means 65.535 ports per address, giving you 16.514.820 usable ports. Usually sane people predicts between 700 and 1000 ports per user, and that gives you between 16.514 and 23.592 possible users that you can serve at the same time and connect them to legacy IPv4 world. Now everyone will have to figure out if that's enough or not. :) Cheers, Jan From jan at go6.si Tue Sep 26 19:02:00 2017 From: jan at go6.si (Jan Zorz - Go6) Date: Tue, 26 Sep 2017 19:02:00 +0200 Subject: [address-policy-wg] 2017-03, New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <011501d336e0$13923700$3ab6a500$@a2b-internet.com> References: <7a584263-a004-8aaf-544a-108b30001581@gmail.com> <59C6C6E8.1000407@foobar.org> <8F620286-4C3F-443E-82FC-56F2F13F1CF0@steffann.nl> <011501d336e0$13923700$3ab6a500$@a2b-internet.com> Message-ID: On 26/09/2017 17:56, Erik Bais wrote: >> Now everyone will have to figure out if that's enough or not. :) > > That is clearly not enough... you are asking the obvious here Jan... ;-) Well, yes and no. We are talking about new entrants here, companies that are fresh new on the market and usually this folx does not build a huuuge network from the very start. If we forget the regulatory restriction possibility in the future, a local residential network of 10k to 20k users is still not too bad for a starter and maybe that might even encourage the increased competition to big-old-boys that will not be able to get more IPv4 resources at all ;) Cheers, Jan > > Erik > > -----Oorspronkelijk bericht----- > Van: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] Namens Jan Zorz - Go6 > Verzonden: dinsdag 26 september 2017 10:27 > Aan: address-policy-wg at ripe.net > Onderwerp: Re: [address-policy-wg] 2017-03, New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) > > On 24/09/2017 00:38, Sander Steffann wrote: >> ...or change the /22 to /24 and keep giving newcomers a tiny bit of >> addresses for a while longer (what is currently being proposed). > > Hey, > > A quick math what a /24 can give you if you use if for > translation/transition purposes only (NAT64 or A+P like MAP-E/T) > > If you connect to your upstream with *their* IP addresses and not break > your /24 into smaller bits and connect your NAT64 or A+P PRR box > directly to that BGP router, use first usable address as a gateway, > second address as an interface address for your translation/transition > box, then you are left with 252 usable addresses for your purpose. That > means 65.535 ports per address, giving you 16.514.820 usable ports. > Usually sane people predicts between 700 and 1000 ports per user, and > that gives you between 16.514 and 23.592 possible users that you can > serve at the same time and connect them to legacy IPv4 world. > > Now everyone will have to figure out if that's enough or not. :) > > Cheers, Jan > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3976 bytes Desc: S/MIME Cryptographic Signature URL: From ggiannou at gmail.com Tue Sep 26 21:20:44 2017 From: ggiannou at gmail.com (George Giannousopoulos) Date: Tue, 26 Sep 2017 22:20:44 +0300 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <1b938879-e953-9d56-5f8f-d40b58da8c9f@tvt-datos.es> References: <397fd725-0403-dca7-539e-1550faa5e0e3@danysek.cz> <99c23a41034545ebb5eef1c212ce128b@elisa.fi> <05D277B2-6F95-43C4-BB7A-D690F134DAB3@heanet.ie> <20170922180427.GN11532@x27.adm.denic.de> <5890ad90-8bb4-3da9-dfdd-3d964d14ecb8@ripe.net> <1b938879-e953-9d56-5f8f-d40b58da8c9f@tvt-datos.es> Message-ID: Hello all, I see pros and cons for both accepting this proposal and rejecting it. One thing I'm curious about.. ARIN has run out of IPv4 space.. Has this stopped any new startup from doing business or what? -- George -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at iptrading.com Tue Sep 26 21:44:55 2017 From: mike at iptrading.com (Mike Burns) Date: Tue, 26 Sep 2017 15:44:55 -0400 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: <397fd725-0403-dca7-539e-1550faa5e0e3@danysek.cz> <99c23a41034545ebb5eef1c212ce128b@elisa.fi> <05D277B2-6F95-43C4-BB7A-D690F134DAB3@heanet.ie> <20170922180427.GN11532@x27.adm.denic.de> <5890ad90-8bb4-3da9-dfdd-3d964d14ecb8@ripe.net> <1b938879-e953-9d56-5f8f-d40b58da8c9f@tvt-datos.es> Message-ID: <02c901d336ff$ed85ddd0$c8919970$@iptrading.com> >I see pros and cons for both accepting this proposal and rejecting it. >One thing I'm curious about.. ARIN has run out of IPv4 space.. >Has this stopped any new startup from doing business or what? -- >George Hi George, It seems like a common belief among the proponents of the various soft-landing policies that new entrants will find the lack of registry-provided IPv4 blocks to be a significant barrier to entry. We sell IPv4 blocks to new entrants quite frequently, and as has been posted on this thread, even a /22 can be extended to cover quite a few customers. Doing the math, the cost per Ipv4 address per customer served (using non-Belgium CGN) turns out to be less significant than most other costs that companies have to incorporate into their plans. If an address costs $15 and it serves 30 customers, the new entrant is spending $.5 per customer for a network component that is intrinsic to the ability to provide service. My guess is that this cost is far less than hardware or even advertising costs per-customer. And ARIN never has had to worry about fixing their final /8 policy to counter attempts to game the system via serial new LIR applications, as in RIPE. ARIN does not have to impose a moratorium on transfers of a certain class of addresses, as in APNIC. In retrospect, I think the ARIN policy was far-sighted and quite effective. I have heard no voices bemoaning the situation here from my perspective as a broker. Finally I wanted to mention that should RIPE implement this policy, address prices would not double, the relation between this policy and pricing is very tenuous. It?s certainly not like the IPv4 market price has a mathematical relationship to the RIPE entrance fee divided by the allocation size for new entries. Now it?s 2000 Euros and you get 1024 addresses. There is no relationship between those numbers that yields a current price ($15) and the current price has risen over the last two years while the RIPE fees and allocation size has not changed. I am against the policy as written, I think the better route would be to reach complete exhaust everywhere and a enable a global transfer market without ?classes? of addresses. Regards, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfriacas at fccn.pt Tue Sep 26 23:42:30 2017 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Tue, 26 Sep 2017 22:42:30 +0100 (WEST) Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: <397fd725-0403-dca7-539e-1550faa5e0e3@danysek.cz> <99c23a41034545ebb5eef1c212ce128b@elisa.fi> <05D277B2-6F95-43C4-BB7A-D690F134DAB3@heanet.ie> <20170922180427.GN11532@x27.adm.denic.de> <5890ad90-8bb4-3da9-dfdd-3d964d14ecb8@ripe.net> <1b938879-e953-9d56-5f8f-d40b58da8c9f@tvt-datos.es> Message-ID: Hi George, All, On Tue, 26 Sep 2017, George Giannousopoulos wrote: > Hello all, > I see pros and cons for both accepting this proposal and rejecting it. > > One thing I'm curious about.. ARIN has run out of IPv4 space..? They had this... https://www.arin.net/policy/nrpm.html#four10 ========================================================================== 4.10 Dedicated IPv4 block to facilitate IPv6 Deployment When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous /10 IPv4 block will be set aside and dedicated to facilitate IPv6 deployment. Allocations and assignments from this block must be justified by immediate IPv6 deployment requirements. Examples of such needs include: IPv4 addresses for key dual stack DNS servers, and NAT-PT or NAT464 translators. ARIN staff will use their discretion when evaluating justifications. This block will be subject to a minimum size allocation of /28 and a maximum size allocation of /24. ARIN should use sparse allocation when possible within that /10 block. In order to receive an allocation or assignment under this policy: 1. the applicant may not have received resources under this policy in the preceding six months; 2. previous allocations/assignments under this policy must continue to meet the justification requirements of this policy; 3. previous allocations/assignments under this policy must meet the utilization requirements of end user assignments; 4. the applicant must demonstrate that no other allocations or assignments will meet this need; 5. on subsequent allocation under this policy, ARIN staff may require applicants to renumber out of previously allocated / assigned space under this policy in order to minimize non-contiguous allocations. ========================================================================== > Has this stopped any new startup from doing business or what? Would like to read about that, in the 1st person. Are new startups getting info about IPv6 when they solve (partially or totally) their issues by buying or renting IPv4 address space? -- if they build entirely/exclusively on IPv4, the global pit is getting deeper... (i.e. we know that when a new entrant becomes a LIR, he is going to hear about IPv6...) Thanks, Carlos > -- > George > > From ripe-wgs at radu-adrian.feurdean.net Thu Sep 28 08:56:24 2017 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Thu, 28 Sep 2017 08:56:24 +0200 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: Message-ID: <1506581784.3440084.1120888904.10D06BF1@webmail.messagingengine.com> Hi All, I oppose this proposal. My reasons, or at least most of them, have explained by other people during the last week: - maintaining a lack of incentive for IPv6 deployment ("still have some IPv4") - forcing desegregation, as if the problem is not bad enough already, and possibility to make things even worse (by creating new pretext for "longer than /24 in GRT"). I would also add some other reasons: - community's duty/responsibility for future generations : apart what it has already been discussed (get v4 on the market, get it from upstream, or even "really need to get v4 ?"), we are representing here the RIP*E* community, with limited geographical scope. However, the policy is quite lax at the moment concerning the out-of-region use of resources, basically allowing an out-of-region entity to get resources with a sole promise to use *some* of them in-continent. - this brings us to the next point : with RIPE region being for the moment the second-richest RIR (v4-wise) and the lax rules regarding out-of-region use, I would not like RIPE NCC to become the world's "last resort" registry for v4 resources (or any other resources for that matter). And if I were to agree with the proposal (which is not the case right now), I would say that some thresholds should be used. Like /10 or /11 available for /23 allocations and /12 available for /24. Under no circumstance /24 now. -- Radu-Adrian FEURDEAN From cfriacas at fccn.pt Thu Sep 28 13:21:05 2017 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Thu, 28 Sep 2017 12:21:05 +0100 (WEST) Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <1506581784.3440084.1120888904.10D06BF1@webmail.messagingengine.com> References: <1506581784.3440084.1120888904.10D06BF1@webmail.messagingengine.com> Message-ID: On Thu, 28 Sep 2017, Radu-Adrian FEURDEAN wrote: > Hi All, Hi, Thanks for your input! > I oppose this proposal. My reasons, or at least most of them, have > explained by other people during the last week: > - maintaining a lack of incentive for IPv6 deployment ("still have some > IPv4") The proposal tries to remain neutral about that. But you are not alone on this point. > - forcing desegregation, as if the problem is not bad enough already, > and possibility to make things even worse (by creating new pretext for > "longer than /24 in GRT"). Any prefix can be split into /24s and still remain globally routable. Going beyond /24 is really not in this proposal. A new proposal would be needed for that... > I would also add some other reasons: > - community's duty/responsibility for future generations : apart what > it has already been discussed (get v4 on the market, get it from > upstream, or even "really need to get v4 ?"), we are representing here > the RIP*E* community, with limited geographical scope. However, the > policy is quite lax at the moment concerning the out-of-region use of > resources, basically allowing an out-of-region entity to get resources > with a sole promise to use *some* of them in-continent. If you disagree with the current "lax" status, why not build a new proposal? We don't need to address everything with just one proposal... > - this brings us to the next point : with RIPE region being for the > moment the second-richest RIR (v4-wise) and the lax rules regarding > out-of-region use, I would not like RIPE NCC to become the world's > "last resort" registry for v4 resources (or any other resources for > that matter). It's a valid viewpoint. I would also agree with "less lax", but that would be a different proposal. > And if I were to agree with the proposal (which is not the case right > now), I would say that some thresholds should be used. Like /10 or /11 > available for /23 allocations and /12 available for /24. Under no > circumstance /24 now. I can also agree with that, but it's just a matter of sizing it. If v2.0, v3.0, v4.0, ... is eventually approved/adopted, it may be that there isn't a /12 to do this anymore... So, we really didn't focus in the task of establishing barriers/boundaries. But we might consider this for v2.0, if it helps. :-) Best Regards, Carlos Fria?as > -- > Radu-Adrian FEURDEAN > From jac.kloots at surfnet.nl Fri Sep 29 14:14:55 2017 From: jac.kloots at surfnet.nl (Jac Kloots) Date: Fri, 29 Sep 2017 14:14:55 +0200 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: Message-ID: <4c452c1c-9011-4e63-f670-5b6dd183629b@surfnet.nl> All, On 21/09/2017 13:43, Marco Schmidt wrote: > Dear colleagues, > > A new RIPE Policy proposal, 2017-03, "Reducing Initial IPv4 Allocation, > aiming to preserve a minimum of IPv4 space", is now available for discussion. > > The goal of this proposal is to reduce the IPv4 allocations made by the RIPE NCC > to a /24 (currently a /22) and only to LIRs that have not received an IPv4 allocation > directly from the RIPE NCC before. > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2017-03/ > > As per the RIPE Policy Development Process (PDP), the purpose of this > four-week Discussion Phase is to discuss the proposal and provide feedback to the proposer. > > At the end of the Discussion Phase, the proposer, with the agreement of > the RIPE Working Group Chairs, decides how to proceed with the proposal. I oppose this proposal. There is a healthy trade in IP addresses which doens't justify to prolong the suffering of these last /8 allocations One of the pro's in the arguments: 'Opening multiple LIR accounts will be less attractive if this policy is approved -- because each new LIR would get less IPv4 space for the same amount of money. Thus, decreasing of the free IPv4 available pool is likely to slow down.' Seems to me this could be solved in a fairly easy different way and not by handicapping new LIRs with other reasoning for becoming an LIR than trading IPs. The 24 month transfer restriction could easily be extended to 4 or maybe even 6 or 8 years. LIRs erected with other means than trading IPs won't have a single problem with an extended transfer restriction. So a change in RIPE-682 would be a better solution to prevent opening multiple LIR accounts for trade. Regards, Jac From ripe-wgs at radu-adrian.feurdean.net Sat Sep 30 13:36:06 2017 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Sat, 30 Sep 2017 13:36:06 +0200 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: <1506581784.3440084.1120888904.10D06BF1@webmail.messagingengine.com> Message-ID: <1506771366.1787297.1123335728.4C550490@webmail.messagingengine.com> On Thu, Sep 28, 2017, at 13:21, Carlos Fria?as wrote: > > - forcing desegregation, as if the problem is not bad enough already, > > and possibility to make things even worse (by creating new pretext for > > "longer than /24 in GRT"). > > Any prefix can be split into /24s and still remain globally routable. > > Going beyond /24 is really not in this proposal. A new proposal would be > needed for that... The issue is not with what it's in the proposal, the issue is the consequences, direct or indirect. > > I would also add some other reasons: > > - community's duty/responsibility for future generations : apart what > > it has already been discussed (get v4 on the market, get it from > > upstream, or even "really need to get v4 ?"), we are representing here > > the RIP*E* community, with limited geographical scope. However, the > > policy is quite lax at the moment concerning the out-of-region use of > > resources, basically allowing an out-of-region entity to get resources > > with a sole promise to use *some* of them in-continent. > > If you disagree with the current "lax" status, why not build a new > proposal? We don't need to address everything with just one proposal... This a simplist (almost childish) answer to a more complex issue. Even if we start with only the "out-of-region" issue, we will quickly get into the needs-based check, which I have been explained several times by several people that it can no longer work in RIPE-land. There is also the issue of what should happen with those not respecting the policies. Right now we seem to be in a situation where we have laws but no police. Should we continue on that direction (more laws, still no police) or should we just remove the root cause for breaking the law (removing the law may also be an option - even if not really the best) ? > It's a valid viewpoint. I would also agree with "less lax", but that > would be a different proposal. I would support such a proposal, but I doubt that it will have the expected effect in the short-medium term. > I can also agree with that, but it's just a matter of sizing it. If v2.0, > v3.0, v4.0, ... is eventually approved/adopted, it may be that there > isn't a /12 to do this anymore... > So, we really didn't focus in the task of establishing > barriers/boundaries. But we might consider this for v2.0, if it helps. :-) So I'll wait a "better" v2.0 .... or v3.0, or v4.0 ...... :) -- Radu-Adrian FEURDEAN From cfriacas at fccn.pt Sat Sep 30 23:35:20 2017 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Sat, 30 Sep 2017 22:35:20 +0100 (WEST) Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: <1506771366.1787297.1123335728.4C550490@webmail.messagingengine.com> References: <1506581784.3440084.1120888904.10D06BF1@webmail.messagingengine.com> <1506771366.1787297.1123335728.4C550490@webmail.messagingengine.com> Message-ID: Hi, On Sat, 30 Sep 2017, Radu-Adrian FEURDEAN wrote: > On Thu, Sep 28, 2017, at 13:21, Carlos Fria?as wrote: >>> - forcing desegregation, as if the problem is not bad enough already, >>> and possibility to make things even worse (by creating new pretext for >>> "longer than /24 in GRT"). >> >> Any prefix can be split into /24s and still remain globally routable. >> >> Going beyond /24 is really not in this proposal. A new proposal would be >> needed for that... > > The issue is not with what it's in the proposal, the issue is the > consequences, direct or indirect. Do you mean people need to agree or disagree with what is _not_ in this proposal? >>> I would also add some other reasons: >>> - community's duty/responsibility for future generations : apart what >>> it has already been discussed (get v4 on the market, get it from >>> upstream, or even "really need to get v4 ?"), we are representing here >>> the RIP*E* community, with limited geographical scope. However, the >>> policy is quite lax at the moment concerning the out-of-region use of >>> resources, basically allowing an out-of-region entity to get resources >>> with a sole promise to use *some* of them in-continent. >> >> If you disagree with the current "lax" status, why not build a new >> proposal? We don't need to address everything with just one proposal... > > This a simplist (almost childish) answer to a more complex issue. No need to go into "insult-mode". I was merely suggesting new proposals are always a possibility. > Even > if we start with only the "out-of-region" issue, we will quickly get > into the needs-based check, which I have been explained several times by > several people that it can no longer work in RIPE-land. Yes, needs-based checks will not work. But i'm probably missing something: current status is everyone gets one last /22 with no questions asked; the proposal aims to change that into a /24, still with no questions asked. Unless i'm not seeing something, the proposal doesn't really try to (re-)introduce needs-base checks. > There is also the issue of what should happen with those not respecting > the policies. Address space returning to RIPE's pool...? > Right now we seem to be in a situation where we have laws > but no police. There is no procedure that allows someone to identify something strange and then report it to the NCC, so they can evaluate it? I've googled a bit, and found this... https://www.ripe.net/report-form Never used it, though :-) > Should we continue on that direction (more laws, still no > police) 2017-03, is not about a new "rule". It's about changing an existing rule. > or should we just remove the root cause for breaking the law > (removing the law may also be an option - even if not really the best) ? I don't believe in "no rules". Otherwise, i wouldn't be co-authoring a policy proposal :-) >> It's a valid viewpoint. I would also agree with "less lax", but that >> would be a different proposal. > > I would support such a proposal, but I doubt that it will have the > expected effect in the short-medium term. First step is to build it, then search for its approval. And yes, the PDP doesn't work by just snapping fingers :-) >> I can also agree with that, but it's just a matter of sizing it. If v2.0, >> v3.0, v4.0, ... is eventually approved/adopted, it may be that there >> isn't a /12 to do this anymore... >> So, we really didn't focus in the task of establishing >> barriers/boundaries. But we might consider this for v2.0, if it helps. :-) > > So I'll wait a "better" v2.0 .... or v3.0, or v4.0 ...... :) There is a lot of input already. But let's see how it goes. Cheers, Carlos > -- > Radu-Adrian FEURDEAN >