- address-policy-wg - mailman.ripe.net

New on RIPE Labs: All Quiet in the IPv4 Internet?
by Mirjam Kuehne 21 Sep '16

21 Sep '16

Dear colleagues, Please find this new article on RIPE Labs by Philipp Richter: All Quiet in the IPv4 Internet? The number of new IPv4 allocations has stagnated, address markets have taken off, and address sharing mechanisms (for example, Carrier-Grade NAT) are on the rise as operators try to squeeze the most out of their IPv4 address space. But what is really happening in the IPv4 address space? Measuring address space activity at scale is difficult. There’s really no single vantage point that can capture all the activity. Read more on RIPE Labs (this article was originally published on the APNIC blog): https://labs.ripe.net/Members/philipp_richter/all-quiet-in-the-ipv4-internet Kind regards, Mirjam Kuehne RIPE NCC

1 0

RIPE 72 Address Policy WG Draft Minutes
by Marco Schmidt 06 Sep '16

06 Sep '16

Dear colleagues, The draft minutes from the Address Policy Working Group sessions at RIPE 72 have now been published: https://www.ripe.net/participate/ripe/wg/ap/minutes/ripe-72 Please let us know of any corrections or amendments. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

1 0

Update on ALLOCATED PI/UNSPECIFIED
by Ingrid Wijte 22 Aug '16

22 Aug '16

Dear colleagues, During RIPE 72, the RIPE NCC was asked to suggest a way forward with regards to the unclear situation arising from address blocks in the RIPE Database with the status ALLOCATED PI or ALLOCATED UNSPECIFIED. We want to give you an update on this work and ask for your input. BACKGROUND Although PI assignments made by LIRs have the same status in the RIPE Database, it is not clear if resource holders with assignments from LIRs have the same rights as resource holders with those issued by the RIPE NCC. The community, mainly End Users, has asked the RIPE NCC to clarify the situation. In the early days of the RIPE NCC, a small number of LIRs received allocations with the status ALLOCATED PI or ALLOCATED UNSPECIFIED. From these address blocks, LIRs could assign ranges with the status ASSIGNED PI. The RIPE community later decided that the RIPE NCC should be the only party assigning ranges with ASSIGNED PI to End Users. It was not clear what the status of the assignments that had already been made should be. ACTION TAKEN At RIPE 71, the Address Policy Working Group asked the RIPE NCC to check the actual assignment status with the holders of these allocations. We contacted all of the LIRs involved and around 50% said they had no contact with holders of assignments with the status ASSIGNED PI within their allocations. Several allocations containing only PA assignments were converted from ALLOCATED UNSPECIFIED to ALLOCATED PA following communication with LIRs. The RIPE NCC presented these results to the Address Policy Working Group at RIPE 72. The WG stressed that data accuracy must have the highest priority. It was further suggested that the RIPE NCC should follow up with the LIRs on a case-by-case basis, following the principles outlined below. The WG agreed that, where the LIR can document a mutual agreement that they administer the address space, a conversion from PI to PA should take place. In all other cases, assignments with the status ASSIGNED PI should be treated as being assigned by the RIPE NCC. It was also stated that LIRs should not register any new assignments with the status ASSIGNED PI, as policy no longer allows for new IPv4 PI assignments (with the exception of IXP PI assignments from our reserved address pool). APPROACH The RIPE NCC will contact the 38 LIRs holding allocations that contain address blocks with the status ASSIGNED PI (3,600 inetnum objects in total). In the following months, these LIRs will check if their RIPE Database entries are still correct. Each LIR will check their records and with their customers to see under what conditions the assignments were originally provided. After the LIRs have finished their research, the RIPE NCC will: - Convert assignments to ASSIGNED PA if it can be documented that the administrative responsibility lies with the LIR - Follow up directly with resource holders of ASSIGNED PI to apply the RIPE policy, “Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region”. The PI assignments will become part of the address space managed by the RIPE NCC just like all other PI space. Once the resource holders have fulfilled the contractual requirements, they will have the same rights and obligations as any other End User of PI space. - Split the allocations to separate the PI assignments and convert the blocks that remain with an LIR to ALLOCATED PA. We suggest giving these LIRs until the end of January 2017 to clarify the status of the assignments within their ALLOCATED PI/UNSPECIFIED allocations. In situations where a dispute arises between the LIR and the assignment holder about the administrative responsibility, the RIPE NCC will do its best to support a fair solution. We welcome your feedback on this suggested approach. Please provide your input before 12 September 2016. Kind regards, Ingrid Wijte Assistant Manager Registration Services RIPE NCC

19 40

2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy)
by Marco Schmidt 16 Aug '16

16 Aug '16

Dear colleagues, The Discussion Period for the policy proposal 2016-03, "Locking Down the Final /8 Policy" has been extended until 15 July 2016. The goal of this proposal is to ban transfers of allocations made under the final /8 policy. The text of the proposal has been revised based on mailing list feedback and we have published a new version (2.0) today. As a result, a new Discussion Phase has started for the proposal. Some of the differences from version 1.0 include: - Several restrictions have been removed - Adds a recommendation that LIRs should conserve whole or part of their final /22 allocation for interoperability purposes You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2016-03 We encourage you to review this policy proposal and send your comments to <address-policy-wg(a)ripe.net>. Regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

38 142

New AS Number Blocks allocated to the RIPE NCC
by Ingrid Wijte 01 Aug '16

01 Aug '16

Dear Colleagues, The RIPE NCC has received the following AS Number Blocks from the IANA on 29 July 2016. 64396-64495 204288-205211 205212-206235 206236-207259 You may want to update your records accordingly. Best regards, Ingrid Wijte Registration Services Assistant Manager RIPE NCC

1 0

Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy)
by remco.vanmook＠gmail.com 22 Jul '16

22 Jul '16

He thought it needed to be withdrawn because he concluded that there was no consensus - and that conclusion is not his to make. So that's what Gert responded to. Remco Sent from my HTC ----- Reply message ----- From: "Riccardo Gori" <rgori(a)wirem.net> To: <address-policy-wg(a)ripe.net> Subject: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) Date: Thu, Jul 21, 2016 20:29 I see he said "I think". I think list exists because everyone should be left free to express his own opinion, that's not taking decision. regards Riccardo Il 21/07/2016 20:07, Gert Doering ha scritto: Hi, On Thu, Jul 21, 2016 at 08:40:38PM +0300, Aleksey Bulgakov wrote: I think, it is time to withdraw this proposal due to we haven't reached the consensus. This is not your call to make. Gert Doering -- APWG chair -- Ing. Riccardo Gori e-mail: rgori(a)wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info(a)wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) --------------------------------------------------------------------

6 9

ipv6 assignments
by Nick Hilliard 23 Jun '16

23 Jun '16

Apropos of one of those endless arguments on the Internet (where everything is true, because it says it on the Internet), I had a discussion with Kurtis about the definition of an ipv6 "End Site", which is specified in section 2.9 of RIPE-655. This says: > 2.9. End Site > > An End Site is defined as an End User (subscriber) who has a business or legal relationship (same or associated entities) with a service provider that involves: > > - that service provider assigning address space to the End User > - that service provider providing transit service for the End User to other sites > - that service provider carrying the End User's traffic > - that service provider advertising an aggregate prefix route that contains the End User's assignment Our reading of this is that each of these conditions is mandatory, i.e. logical AND, because logical OR does not make sense. Term 2.9.2 states that an ipv6 End Site is only an End Site if the service provider is providing transit service for the End User to other sites. Section 5.4 and 5.4.1 then state: > LIRs must make IPv6 assignments in accordance with the following provisions. > > End Users are assigned an End Site assignment from their LIR or ISP. So the policy appears to state that an IPv6 assignment can only be issued to an end user if the end user has a transit service to more than one site, presumably ipv4 because demanding ipv6 connectivity would create a circular requirement. In other words, ipv4 connectivity to multiple different sites appears to be a mandatory prerequisite in order to get an IPv6 assignment. Could someone in the RIPE NCC please confirm that this policy is being policed as stated? And if not, when can we expect all non-compliant assignments in the RIPE NCC service region to be revoked? Nick

5 10

another way to achieve the original motives of post-exhaustion policy
by Mikael Abrahamsson 21 Jun '16

21 Jun '16

I just had a thought. What we're trying to do is to make sure there are IPv4 addresses available to new entrants. We're trying to do this by making a LIR get one post-exhaustion /22 each. The LIR fee is the limiting factor in trying to stop people from getting many /22:s. People have been trying to game this, by getting /22 and closing the LIR, thus avoiding the LIR fee. Changes in the policy has been all about trying to limit transfers etc, setting policy from what should happen with /22s, stopping transfers (so people still have to pay LIR fees, one per /22 etc). Since it's actually the post-exhaustion /22 we're after why not do this: The post-exhaustion /22 comes with a fee that is equivalent to the LIR fee. If a LIR contains one post-exhaustion /22, then this fee is waived. Doesn't this just solve the problem everybody is arguing about? Now all of a sudden it's not cheap to get multiple /22s, and we don't care any more if people keep their LIRs open or not, it still costs the same. -- Mikael Abrahamsson email: swmike(a)swm.pp.se

4 4

Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy)
by Arash Naderpour 18 Jun '16

18 Jun '16

Hi, This policy can affect the members that already received some /22 or smaller blocks (from 185/8 range) from the market. They already paid to sellers to obtain those blocks and this policy make it impossible for them to transfer it out later if they don't need it. I'm opposing the policy, it make unnecessary limitation and put a part of community in an unfair situation. If returning an allocation is something visible it can be done to any allocation, not just the smallest ones. Regards, Arash Naderpour

3 2

Create FAQ? (was: Re: IPv4 reserved space)
by Nick Hilliard 14 Jun '16

14 Jun '16

Tore Anderson wrote: > If by some miracle you would be able to pull it all off, keep in mind > that the ~107M addresses gained by the RIPE NCC would all be used up > within two years if we return to the pre-depletion allocation policy > and consumption rate. Ask yourself: «then what?» > > Maybe you can now see why folks are telling you that this would be a > colossal waste of time APWG Chairs, Is there any possibility of creating a FAQ? There are a bunch of issues which are coming up repeatedly, of which this is one. Nick

4 4

IPv4 reserved space
by NTX NOC 14 Jun '16

14 Jun '16

Dear all, As we see ISPs and community would like to have more IPv4 space in use. I would like to ask a question what do people think about other side of IPv4 numeration space. Because we have in IPv4 a lot of addresses not in use at all but that space could be easy used. 240.0.0.0/4 Reserved (former Class E network) RFC 1700 it's 16 */8 networks. More then 256 Millions of routable and never used IPv4. 185/8 network has about 6.4M free and total RIPE has about 15M free IPv4 and we all say 185/8 will be enough for 2-3 years and rest - for some more time. But 256 M Ipv4 space could be enough for years! Space reserved for future Use. But will the future come to us or not? https://en.wikipedia.org/wiki/IPv4 https://tools.ietf.org/html/rfc1700 Is far as I see routers could easy start to use that IP space. People spend a lot of time and money to get some IPs but not to ask IANA to allow use this space. Technically it's very easy to start use IPs from such ranges. What does community thinks about it? Yuri

12 23

Re: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space
by Alexander Koeppe 13 Jun '16

13 Jun '16

I don't understand how much time and energy is being put into the discussion about keeping vintage IP alive. This time and energy would be better off spent in just deploying v6. It's just not that difficult. You just need to develop a stepwise approach. A one-shot would probably fail. -- Alex > Am 11.06.2016 um 22:35 schrieb Gert Doering <gert(a)space.net>: > > Hi, > >> On Sat, Jun 11, 2016 at 10:14:11PM +0300, NTX NOC wrote: >> About IPv6 - still now in Russia there are no Home ISPs who gives IPv6 >> by default to customers. Nobody wants it, nobody needs it. > > The "nobody needs it" is a misconception. Direct your energy there to > make people understand that IPv4 is game over. > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > <totemomail_info.html> This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you must not copy this message or attachment or disclose the contents to any other person. If you have received this transmission in error, please notify the sender immediately and delete the message and any attachment from your system. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not accept liability for any omissions or errors in this message which may arise as a result of E-Mail-transmission or for damages resulting from any unauthorized changes of the content of this message and any attachment thereto. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not guarantee that this message is free of viruses and does not accept liability for any damages caused by any virus transmitted therewith. Click http://www.merckgroup.com/disclaimer to access the German, French, Spanish and Portuguese versions of this disclaimer.

14 26

2016-03 New Policy Proposal (Locking Down the Final /8 Policy)
by Marco Schmidt 13 Jun '16

13 Jun '16

Dear colleagues, A new RIPE Policy proposal 2016-03, "Locking Down the Final /8 Policy" is now available for discussion. The goal of this proposal is to limit IPv4 from the remaining address pool to one /22 per LIR (regardless of how it was received). These “final /22” allocations will receive a separate status with several restrictions: - These allocation are not transferrable - LIRs may only retain one final /22 following a merger or acquisition - Sub-allocations are not possible - Reverse delegation authority can not delegated to another party You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2016-03 We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 15 June 2016. Regards Marco Schmidt Policy Development Officer RIPE NCC

24 47

Re: [address-policy-wg] IPv6 deployment
by Arash Naderpour 13 Jun '16

13 Jun '16

Hi Jim, Agree here with you, this is not appropriate to discuss how to exploit the existing gaps here in APWG, I was just trying to explain that technical difficulties are not the only reason IPv6 is not deployed everywhere. It should be first be available and possible (from legal point of view) to deploy it which is not yet in all area. Regards, Arash Naderpour -----Original Message----- From: Jim Reid [mailto:jim@rfc1035.com] Sent: Monday, 13 June 2016 2:15 AM To: Arash Naderpour <arash_mpc(a)parsun.com> Cc: RIPE Address Policy WG List <address-policy-wg(a)ripe.net> Subject: IPv6 connectivity in Iran > On 12 Jun 2016, at 16:30, Arash Naderpour <arash_mpc(a)parsun.com> wrote: > > As an example in Iran there is only one exit point (AS12880 and AS48159 belongs to one organization) from country to global carriers controlled by government and as they have no LI platform yet on IPv6 there is simply no IPv6 service availability or possibility for Iranian service providers. > > There is no possibility to have a direct peering with a global carrier and as a result no native IPv6 connectivity yet. there is also no IXP in the country. Well that lack of IPv6 appears to be a major gap in the market and a worthwhile business opportunity with huge growth potential. So is the lack of an in-country IXP. IMO it’s up to the Iranian Internet community to tackle these issues and make the most of these business opporrtunities. It is probably inappropriate for this WG to discuss how to exploit these gaps. They can’t really be helped (or hindered) by RIPE address policy anyway. Mind you if anyone is minded to set up an IXP in Iran, they will have to move quickly if they need/want some IPv4 from the NCC for local interconnect and peering. PS: Apologies for a meaningful and relevant Subject: header.

6 7

Re: [address-policy-wg] IPv6 deployment
by Arash Naderpour 13 Jun '16

13 Jun '16

The point is that not all countries are the same when it comes to rules , some regulatory or government organizations may force ISPs in some area to stick with IPv4, as they simply don't have IPv6 ready LI platforms. I'm sure that there are some plans to deploy IPv6 in all countries soon or later it would be done (even Iran has a v6 road map), but telling others to go and deploy IPv6 (or it is not difficult to deploy) does not change the fact that there are more limitations out there. anyway, thanks for your thoughtful advises. Regards, Arash P.S even in Australia the biggest service provider (Telstra) is not providing IPv6 service to residential customers as of today, -----Original Message----- From: Gert Doering [mailto:gert@space.net] Sent: Monday, 13 June 2016 3:42 AM To: Arash Naderpour <arash_mpc(a)parsun.com> Cc: 'Alexander Koeppe' <Alexander.Koeppe(a)merckgroup.com>; address-policy-wg(a)ripe.net Subject: Re: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space Hi, On Mon, Jun 13, 2016 at 12:39:59AM +1000, Arash Naderpour wrote: > And I don't understand why some people think that everyone can deploy > IPv6, it is simply not available everywhere. > It is not about difficulty, it is about possibility. Work with your regulator to *make* it possible - like the rest of the world has. It might take a while, but "not doing anything and complaining that IPv4 has run out" is not the right approach. (You *should* have started to work with your regulator 10+ years ago, it's not like this is coming as a surprise) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

4 4

Re: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy)
by Riccardo Gori 12 Jun '16

12 Jun '16

Hi, although I understand the spirit of this policy in my opinion there's a big problem behind it: seems that has been thought for reasoucers not in use. I really don't get how a space can be de-registered once announced and in use and after have been allocated under regular procedures and business processes. A new entrant would see his investments vanified by a rule that make possibile transferts possbile only for old LIRs that acquired space before 09/2012. I think this really creates barrier to ingress in the market. If a return policy has to be proposed this should address the whole IPv4 RIPE Region space to be fair and catch where IPs are stockpiled and not in use. Anyway we all know that's quite impossible. To address the problem of abuse RIPE NCC should enforce audit and check if the LIR "make assignement(s)" as stated in the policy. This could be a way to get rid of buy/sell just for speculation. I cannot support this policy regards Riccardo -- Ing. Riccardo Gori e-mail:rgori@wirem.net WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying toinfo(a)wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) --------------------------------------------------------------------

19 32

2015-05 Policy Proposal Withdrawn (Last /8 Allocation Criteria Revision)
by Marco Schmidt 02 Jun '16

02 Jun '16

Dear colleagues, The proposal 2015-05, "Last /8 Allocation Criteria Revision" has been withdrawn. It is now archived and can be found at: https://www.ripe.net/participate/policies/archived-policy-proposals/archive… Reason for withdrawal: The proposers decided to withdraw the proposal due to the inability to find an acceptable agreement which satisfied all parties. Regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

2 1

opposition to 2015-04
by Remco van Mook 30 May '16

30 May '16

Dear all, as just mentioned during the address policy session, I'm withdrawing my objection to 2015-04. While I do think a discussion about policy structure still needs to be held, I don't think it should hold up this proposal any longer. This can be fixed after adoption - as long as we're aware. I do maintain my suggestion to put references in place where chapters about transfers are removed from other sections of policy. Kind regards, Remco

9 12

ALLOCATED FINAL and M&As
by William Waites 26 May '16

26 May '16

This suggestion is intended to address the problem of abusively opening many LIRs or many companies to make new members to stockpile addresses from the last /8. First, if there are intended to be special rules applying to these addresses, they should have a special status to make it clear. For the sake of argument ALLOCATED FINAL. This doesn't change anything, it just makes things a bit more explicit. Any organisation should be entitled to at most one such FINAL allocation from RIPE (if we go back to multiple LIR accounts, only one of them may get a FINAL block). FINAL allocations are only for use on the Internet, not for internal, non-announced uses: that is a legitimate use case, but don't squander the last of the pool for that. Transfers of FINAL blocks are only allowed if they are demonstrably in use. "In use" means (1) announced in the global BGP tables and (2) with documentation of deployment in a non-trivial topology, i.e. assigning everything in the /22 to a single host so that it answers ICMP packets doesn't fly. Yes, there are still ways to game this, but the bar is much higher. Yes, it means that the NCC has to do more work to check that transfers are legitimate, but that is a necessary cost for dealing with the problem of the bad actors. --- Motivation/disclosure. HUBS is made up of a dozen or so small rural providers mostly in the south of Scotland. We are an LIR and allocate addresses to them on pretty much the same basis as we get them from RIPE. We encourage them to do IPv6 but made an explicit choice not to dictate or interfere in their internal operations. They may use their IPv4 allocations for "CG"-NAT, or assign them to customers, and we offer advice but not more. Another organisation, WHAN, was set up to do this along similar lines on the west coast (and actually to extend the model by making a distributed IXP for their networks to connect to rather than looking like a transit provider). There is some overlap of people (exactly two) but they operate in a different geographical area and the set of member networks is completely disjoint. At some point it is quite possible that these two organistions will merge. That would be extremely and unnecessarily painful if that meant that networks already assigned and in use had to be returned. These organisations are already operating in areas characterised by market failure, on extremely tight budgets largely reliant on volunteers to provide the only option for decent Internet access. The policy that has been mooted of a rigid rule of exactly one final allocation per organisation would be hugely damaging. Best wishes, William Waites Network Engineer HUBS AS60241

1 0

Join the Address Policy WG Discussions Tomorrow
by Marco Schmidt 24 May '16

24 May '16

Dear colleagues, Tomorrow at RIPE 72, the Address Policy Working Group will be discussing the following policy proposals: - 2015-04, "RIPE Resource Transfer Policies" - 2015-05, "Revision of Last /8 Allocation Criteria" - 2016-03, "Locking Down the Final /8 Policy" While no decisions are made during this session, it’s a good opportunity to discuss the proposals and give feedback directly to the proposers. If you can't attend tomorrow’s session in person, you can participate remotely. The following link will provide you with a live webstream and a chat client. https://ripe72.ripe.net/live/main/ The session begins at 07:00 UTC on 25 May 2016. We encourage you to join the discussion if you have an opinion about one of these proposals. The second Address Policy Working Group session begins at 9:00 UTC on the same day and includes a presentation on "Market Concentration in the Transfer of IPv4 Space”, as well as feedback from the RIPE NCC's Registration Services Department. We invite you to tune in to see these presentations as well. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC

1 0

New on RIPE Labs: Developments in IPv4 Transfers
by Mirjam Kuehne 24 May '16

24 May '16

Dear colleagues, In May 2015, we looked at IPv4 transfers in the RIPE NCC service region and found signs of an emerging market. Both the number and size of transfers conducted under RIPE Policy showed an upward trend in the years 2013-2014. One year later, we take another look. Did this trend continue? What have been the effects of the inter-RIR transfer policy? Please read on RIPE Labs: https://labs.ripe.net/Members/wilhelm/developments-in-ipv4-transfers?pk_cam… Kind regards, Mirjam Kuehne RIPE NCC

1 0

2015-05 Discussion Period extended until 13 June 2016 (Last /8 Allocation Criteria Revision)
by Marco Schmidt 24 May '16

24 May '16

Dear colleagues, The Discussion Period for the proposal 2015-05, "Last /8 Allocation Criteria Revision" has been extended until 13 June 2016. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2015-05 We encourage you to review this policy proposal and send your comments to <address-policy-wg(a)ripe.net>. Regards, Marco Schmidt Policy Development Officer RIPE NCC

12 36

“RIPE 72” has been canceled.
by mostafa shahdadi 23 May '16

23 May '16

“RIPE 72” has been canceled. starts: All-Day, Monday, May 23, 2016 ends: All-Day, Friday, May 27, 2016 location: Copenhagen, Denmark note: now deleted by: mostafa shahdadi --- iCloud is a service provided by Apple. Apple ID: https://appleid.apple.com/choose-your-country/ Support: https://www.apple.com/support/icloud/ww Terms and Conditions: https://www.apple.com/legal/internet-services/icloud/ww/ Privacy Policy: https://www.apple.com/legal/internet-services/privacy/ Copyright 2016 Apple Inc. 1 Infinite Loop, Cupertino, CA 95014, United States. All rights reserved.

1 0

Re: [address-policy-wg] [policy-announce] 2015-05 Discussion Period extended until 13 June 2016 (Last /8 Allocation Criteria Revision)
by alain.bidron＠orange.com 20 May '16

20 May '16

Envoyé depuis mon mobile Orange ----- Reply message ----- De : "Marco Schmidt" <mschmidt(a)ripe.net> Pour : "policy-announce(a)ripe.net" <policy-announce(a)ripe.net> Objet : [policy-announce] 2015-05 Discussion Period extended until 13 June 2016 (Last /8 Allocation Criteria Revision) Date : ven., mai 20, 2016 15:03 Dear colleagues, The Discussion Period for the proposal 2015-05, "Last /8 Allocation Criteria Revision" has been extended until 13 June 2016. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2015-05 We encourage you to review this policy proposal and send your comments to <address-policy-wg(a)ripe.net>. Regards, Marco Schmidt Policy Development Officer RIPE NCC _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.

1 0

comment on "Revision of Last /8 Allocation Criteria"
by Kai Rottleb 20 May '16

20 May '16

Dear Mr. Schmidt, I want to make a comment on your proposal "Revision of Last /8 Allocation Criteria“. https://www.ripe.net/participate/policies/proposals/2015-05 <https://www.ripe.net/participate/policies/proposals/2015-05> We became RIPE member about 1,5 years ago. We have received one single /22 subnet. Due to groth requirement, we have purchased an additional /23 subnet a few weeks ago in an auction. In you proposal it is stated that for an additional /22 allocation the member „must not have transferred any IPv4 address space before“. I hope this requirement only concernes transfers away from us, not to us. Otherwise I find it very unfair that we are punished for organizing additional subnets in a legal way for our regular business. We don’t intend to trade with those IPs. Best regards, Kai Rottleb -- KNT Internet, Inh. Kai Rottleb Riethnordhaeuser Str. 71 99189 Hassleben, Germany Mail: kai.rottleb(a)knt.io <mailto:kai.rottleb@knt.io> Tel: 036201 61055 Mobil: 01723971017

2 1