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

Re: [address-policy-wg] 2015-04 New Draft Documents and Impact Analysis Published (RIPE Resource Transfer Policies)
by Erik Bais 14 Mar '16

14 Mar '16

Hi, As we are almost at the end of the current phase (after today. ) I would like to ask the AP-WG Chairs if they agree to add at least 2 weeks additional time to the discussion time to make sure that all pros and cons are discussed. Currently we are looking at an objection from Remco v. Mook ( with no hats ) that there might be some future issue on similar policy changes that might provide a policy issue as the previous version of the draft had. While I understand his line of thinking, I dont think that we give the legal team enough credit to spot future issues similar as the one in the past draft.. I like to think there is a learning curve And I will also invite Remco to keep reading future policy proposals from myself and others to make sure that there arent any un-intentional issues that might be introduced in future policy. Having said that, he also stated that there is currently nothing wrong with the version at the table. On the final remark of Remco, if we need to see if we need to review the actual current structure of the policies.. I agree and I would like to have a good discussion on that. But that is to me a discussion outside the scope of this policy proposal. On the suggestion of Remco and second by Tore (also with no hats), Tore wrote : > Remco suggested adding references to the new policy document in lieu of > the removed sections in ripe-638, ripe-649, and ripe-655. I would not > object to that. This was later also agreed to by a (+1) from Sascha Luck (also without any hats), Guy Chilton (Again .. no hats..) And if we agree that the blunt removal of the transfer text in the current affected policies and having a single transfer document isn't clear enough, I'm not against adding a reference to the new proposed transfer policy document. The only response opposing to the current structure is Peter Koch. Peter stated that he is : > "Generally I'm always nervous when policy/legislation is > "streamlined" by "just editorial changes", and also recent experience here > would suggest extreme caution. Things get complicated when they are > taken out of their respective context (tempus and locus)." And I agree partially with him. Doing things with caution is something that we are all part of here.. And I think that we have proven that we are very careful on making certain changes. The biggest change here is indeed the editorial one, however that is to avoid in doing large changes while also doing editorial changes .. it was clear to everyone that the editorial changes was desired by the majority of the community when the initial changes / transfer policy text was written into the policies.. and this was the 'clean-up and stream-line action.' > At least, the work is incomplete as proposed now, simply because the > affected policies will have to be re-published with a new number and timestamp, > so the (outdated) references will have to be adjusted (this includes > evaluation and thus is more than a simple editorial change) and now > obsolete text ought to be dealt with accordingly. The necessity to > add normative references to a new omnibus document has already been mentioned. I'm reading this that Peter could live with the suggestion done by Remco for the references.. if we are going that route.. And from what I've heard, a change like Remco suggested, would not require a complete rehash into the PDP or redoing any phases again. I hope that with the current summary I have given a quick view of where I think we are ... And if Sander and Gert don't mind, I would like to ask to extend the discussion period for 2 weeks to allow for additional comments on this email and perhaps other insights. Regards, Erik Bais Author of 2015-04 ... aka ... The mad hatter ...

4 4

New and Improved IPv4 Address Space Chart
by Marco Schmidt 10 Mar '16

10 Mar '16

Dear colleagues, During policy discussions, we often see people asking how long the RIPE NCC’s available IPv4 pool will last. This is a good question, as more than three years after the last /8 policy was activated, we still have almost an entire /8 still remaining in our pool. This is made more confusing by the regular allocations we have been receiving from IANA since 2014, which have been counteracting the reduction in addresses that we should have seen due to /22 allocations. To more accurately show the status of our remaining pool, we have updated our IPv4 Address Space Chart, which you can find here: https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhausti… The updated chart makes the distinction between addresses from the last /8, and addresses that were received from IANA’s Recovered IPv4 Pool (as well as addresses recovered from our service region). We have also published a short article on RIPE Labs with some additional detail about our IPv4 pool: https://labs.ripe.net/Members/marco_schmidt/taking-a-closer-look-at-the-las… We hope this will help to inform the community’s policy discussions. Kind regards Marco Schmidt Policy Development Officer RIPE NCC

2 1

2015-04 Review Period extended until 22 March 2016 (RIPE Resource Transfer Policies)
by Marco Schmidt 07 Mar '16

07 Mar '16

Dear colleagues, The Review Period for the proposal 2015-04, "RIPE Resource Transfer Policies" has been extended until 22 March 2016. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2015-04 You can find a summary of the current proposal discussion at: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2016-March/010966… 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

1 0

2015-04 New Draft Documents and Impact Analysis Published (RIPE Resource Transfer Policies)
by Marco Schmidt 01 Mar '16

01 Mar '16

Dear colleagues, The draft documents for version 3.0 of the policy proposal 2015-04, "RIPE Resource Transfer Policies" have now been published, along with an impact analysis conducted by the RIPE NCC. The goal of this proposal is to create a single document with all relevant information regarding the transfer of Internet number resources. Some of the differences from version 2.0 include: - clarification in the policy text about entities that can receive a transfer - further clarification in the policy text and policy summary regarding the 24-month holding period for scarce resources You can find the full proposal and the impact analysis at: https://www.ripe.net/participate/policies/proposals/2015-04 And the draft documents at: https://www.ripe.net/participate/policies/proposals/2015-04/draft We encourage you to read the draft document and send any comments to <address-policy-wg(a)ripe.net> before 3 March 2016. Regards Marco Schmidt Policy Development Officer RIPE NCC

13 13

Working group chair rotation 2
by Sander Steffann 12 Feb '16

12 Feb '16

Hello working group, A year has passed since we implemented our working group chair rotation mechanism, so it is time for one of the APWG chairs to offer his place in case the working group would like to see a change of chair. This time it is my turn to step down, and I will do so in the APWG session at RIPE 72 in Copenhagen. So this is the time for candidates to volunteer and make themselves known here on the list! To be considered candidates must make themselves know before the start of RIPE 72. So, let me start by volunteering again :) I would love to serve this working group for another term as one of its chairs. A short introduction for those who don't know me: * age 39 * shoe size 46, usually not wearing sandals though * university degree in computer science, master on distributed systems for supporting business processes * self-employed IPv6 consultant, customers include ISPs and enterprises * run a small LISP based ISP on AS57771 * attending RIPE meetings since RIPE 49 in Manchester, 2004 (missed none) * address policy working group co-chair since RIPE 54 in Tallinn, 2007 (https://www.ripe.net/participate/ripe/wg/ap/minutes/minutes-from-ripe-54) And now for the future plans * guide the working group in making good policies * maintain a good standard of communication on the mailing list * while also giving space to people with different opinions * aiming to arrive at simple and fair policies for the benefit of the whole community * and explicitly not having a personal agenda while doing so I essentially want to use what I have learned in the last 9 years and continue to guide the working group in always-improving ways. Cheers, Sander Steffann (and thanks to Gert for providing a template to use when writing messages like this: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2015-April/009659…) ;)

22 21

Re: [address-policy-wg] [policy-announce] 2015-04 New Draft Documents and Impact Analysis Published (RIPE Resource Transfer Policies)
by Andreas Worbs 04 Feb '16

04 Feb '16

Hi, i don't know if it's not to late to comment some points in general.. I would suggest to relax the restrictions of a transfer. The restriction were introduced because there were many new LIRs who wanted to grep one of the last IPv4 subnets only to have/sell them. So i think there should be a relaxed solution for longstanding LIRs. Sure, it could be that they request their last /22 only in mind to sell it. But is it really a realistic vision?! However, a transfer within a a group of companies which belongs together should be allowed or at least it should be possible to differ from the strict policies and check the individual case. We have currently the case that we wanted to transfer our last /22 (which were allocated last march) to our 100% subsidiary in the US but it's not possible because of the restrictions. Although we already use two /24 of the /22 there. I don't expect that there will be a near-term solution but i think it's worth to think about it for the future. Am 03.02.16 um 14:58 schrieb Marco Schmidt: > Dear colleagues, > > The draft documents for version 3.0 of the policy proposal 2015-04, > "RIPE Resource Transfer Policies" > have now been published, along with an impact analysis conducted by > the RIPE NCC. > > The goal of this proposal is to create a single document with all > relevant information regarding > the transfer of Internet number resources. > > Some of the differences from version 2.0 include: > > - clarification in the policy text about entities that can receive a > transfer > - further clarification in the policy text and policy summary > regarding the 24-month holding period for scarce resources > > You can find the full proposal and the impact analysis at: > https://www.ripe.net/participate/policies/proposals/2015-04 > > And the draft documents at: > https://www.ripe.net/participate/policies/proposals/2015-04/draft > > We encourage you to read the draft document and send any comments to > <address-policy-wg(a)ripe.net> before 3 March 2016. > > Regards > > Marco Schmidt > Policy Development Officer > RIPE NCC > -- With best regards Artfiles New Media GmbH Andreas Worbs Artfiles New Media GmbH | Zirkusweg 1 | 20359 Hamburg Tel: 040 - 32 02 72 90 | Fax: 040 - 32 02 72 95 E-Mail: support(a)artfiles.de | Web: http://www.artfiles.de Geschäftsführer: Harald Oltmanns | Tim Evers Eingetragen im Handelsregister Hamburg - HRB 81478

1 0

RIPE Policy Proposal 2016-01 Affects Legacy Internet Resource Holders
by Marco Schmidt 28 Jan '16

28 Jan '16

Dear colleagues, We just published RIPE Policy Proposal 2016-01, "Include Legacy Internet Resource Holders in the Abuse-c Policy", to the Anti-Abuse Working Group mailing list. The goal of this proposal is to extend RIPE Document ripe-563, "Abuse Contact Management in the RIPE Database", to Legacy Internet Resource Holders. As this proposal relates to the existing RIPE Policy, "RIPE NCC Services to Legacy Internet Resource Holders", we would like to notify the Address Policy Working Group specifically. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2016-01 We encourage you to review this proposal and send your comments to <anti-abuse-wg(a)ripe.net> before 26 February 2016. Regards, Marco Schmidt Policy Development Officer RIPE NCC

3 2

RPKI Deployment Study
by Gilad, Yossi 15 Jan '16

15 Jan '16

Dear RIPE working group, To improve academic research on interdomain routing security by better understanding network operators' practices and concerns, we've created a short survey: https://docs.google.com/forms/d/1XHxWfUFP1lZRF0lhyDY9wZDGU81I7--65AnzhPF6cf… Survey data will be kept anonymous and will be used to improve research on interdomain routing security. Aggregated results will also be posted to the NANOG list. We appreciate any and all responses to the survey. Thank you, Avichai Cohen (Hebrew University of Jerusalem), Yossi Gilad (Boston University and MIT), Amir Herzberg (Bar-Ilan University), Michael Schapira (Hebrew University of Jerusalem), and Haya Shulman (Fraunhofer SIT)

2 1

Update on the policy proposal :
by Erik Bais 08 Dec '15

08 Dec '15

Hi, As discussed in the AP-WG meeting in Bucharest, we needed to make some changes in the policy text. https://www.ripe.net/participate/policies/proposals/2015-04 The new proposal version will have the following text: 2.0 Transfers within the RIPE NCC Service Region Any legitimate resource holder is allowed to transfer complete or partial blocks of address space or number resources (IPv4, IPv6 and AS Numbers) that were previously allocated or assigned to them by the RIPE NCC or otherwise through the Regional Internet Registry (RIR) system. Resources are excluded from transfers when RIPE Policies mandate their return to the RIPE NCC. Allocated resources may only be transferred to another RIPE NCC member. Provider independent resources may be transferred to: * A RIPE NCC member; or * An entity that has a contractual relationship with a RIPE NCC member in accordance with the RIPE Policy, Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region. I would like to ask the community to review the text and provide feedback on it. We will upload the new version soon. Regards, Erik Bais

1 0

insufficient availability of IPv6 address space for end customers
by Florian Zumbiehl 07 Dec '15

07 Dec '15

Hi everyone, well ... I don't really know where to start, and my best guess is that this sortof must be an FAQ that has been discussed to death before, but then again, maybe my perspective really is something people aren't quite aware of, so here goes my hypothesis: Providers are psychologically incapable of managing IPv6 address space on their own, and RIPE should do something about it before their inability damages IPv6 beyond repair. Yes, I know what you are thinking ... please, bear with me and let me explain. I recently found myself in the market (in .de) for some tunnel with static addresses for my mail and jabber servers and stuff that I run at home, or some small virtual server that I could use to setup the tunnel myself, with one of the requirements being an IPv6 prefix, /56 at least. And guess what? Of all requirements, the biggest problem is the /56. Of course, there is quite a number of providers that still don't offer IPv6 at all ... well, OK, those are hopeless, I guess. But then, there is a large segment of providers which are either incapable of assigning a /56 or larger, or they offer it at prices that make IPv4 addresses seem like an abundant resource in comparison. Now, there might be real technical limitations in some cases that prevent some providers from assigning (or at least from routing) a large(ish) prefix--but my overall impression is that in most cases, this inability to assign non-minimal prefixes does not have its basis in any real technical causes, and not even in business reasons, but rather in some kind of psychological need to not waste address space, a sort of value judgement that is not to be questioned, and that is very difficult to attack with rational arguments. One provider not only told me essentially that I was crazy for wanting to waste so much address space (a notion that I heard more than once), but even went so far as to tell me that /56 assignments were for providers only as per RIPE policy and the most an end customer could get would be a /64 ... not even providing them with the URI of the RIPE allocation and assignment policy helped, they simply couldn't accept that "wasting so much address space" could be anything but morally repugnant, or at least a completely idiotic idea not worth any further consideration (who knows what they really thought, obviously ...). But even the ones that offered a /56 (or larger) prefix for a monthly or one-time fee mostly seemed like they didn't intentionally design their products with smaller prefixes to then be able to sell the "professional version" at a higher price, but rather simply seem to want to cover their increased costs for dealing with this "special requirement", not realizing that they themselves created this situation where my requirement is not met by the standard product, even though they could have done so at no additonal cost to them by simply always assigning a /56 or /48--or in other words, that they themselves created the overhead that the RIPE policy even warns against, and as a side effect presumably also create incentives for customers who aren't that knowledgable to use broken networking setups because of a lack of addresses or the difficulty of obtaining additional addresses. Yes, not all of those providers are RIPE members, but being a RIPE member with a /32 allocation does not seem to prevent you from "saving address space" by making sure you'll never allocate most of it to customers ever. I guess the problem of ensuring availability of addresses has been discussed before, and I guess possible solutions have been rejected for good reasons, I am not really familiar with the history of this at RIPE, and any pointers to FAQs or canonical ML posts or whatever else might bring insight are welcome ... but what I am wondering about specifically is whether it has been considered so far that providers might be incompetent, possibly to the point of not being able to learn unless forced to, at making sensible IPv6 assignments? Should providers be required to always assign at least a /56 unless they can show good technical reasons why that would cause harm? Well, I can see a ton of problems with that approach (How do you enforce that? Does it hurt competent providers? Does it hinder valid business models?), but my impression is that the policy so far assumes that providers make competent decisions, only providing non-binding recommendations regarding minimum allocation sizes, which obviously is completely ignored by providers that are caught up in the address saving mindset of IPv4, leading them to make bad decisions both for themselves and for the long term development of the IPv6 internet (and yes, I found one provider that admitted just that, they told me they were currently overhauling their product offerings and intended to change the standard assignment size in the future, as they had recognized /64 assignments to be a mistake that had happened because they felt they needed to save addresses). How about applying the HD ratio based on the smallest end-site allocation that exists within a provider's prefix (as in: if you assign /64, you only get a /40 unless you can show you have more than ~ 200k /64 assigned)? Maybe even punish small prefixes? If a provider assigns a /64, apply a higher HD ratio? Somehow make it expensive for providers to hoard addresses ... just making it cheap to assign sufficient address space doesn't seem to provide sufficient motivation, so maybe making it expensive to do the wrong thing is what's required? Well, any suggestions welcome (or any arguments why I am an idiot, or maybe just mistaken), also with regards to processes and mechanisms available at RIPE that might help with fixing this problem ... I'll stop here for now ;-) (Oh, and if you feel like you can offer what I am (still) looking for, feel free to drop me an email--but be warned that I don't really intend to spend much money on it, though I'd think it should be easily earned if you have the infrastructure in place, I don't need much traffic and I know to help myself as long as you keep your end of things running ... but that's not really a topic for further discussion on this list, I guess ...) Regards, Florian

4 5

An interesting policy question
by Lu Heng 04 Dec '15

04 Dec '15

Hi I have an policy question regarding Ripe policy before adoption of "no need" policy. We all know that before the no need policy, when Ripe makes an assignment, while the "need" has changed, the assignment become invalid. The question come to what the definition of need. Below I have few examples, please provide your view: First one: Company A provides 100 customer dedicated server service at location A, Ripe makes an assignment for 100 IP for his infrastructure, if, under condition that no other factor was changed, Company A moved his infrastructure to location B, but still providing same service to same customer, does the company's action need to be notified to RIR? And does this action considered invalid the original assignment? Second one: Company A provides web hosting service, but any casted in 3 location, and has provided the evidence of 3 location to the RIR during the time the company getting valid assignment, then A decided to cut 3 location to 2 location, does this invalid original assignment and need to be notified to RIR? So the bottom line is, what is the definition of need, is it defined as the service you are providing or defined as whole package of any of original justification material was provided, if was the later, then does it imply that anything, including location of the infrastructure, upstream providers etc has changed due to operational need, it will be considered as change of purpose of use and need to be notified to RIR? What should be the right interpretation of the policy by then? -- -- Kind regards. Lu

9 20

Re: [address-policy-wg] LIRs with good / bad behavior
by Valentin Panait 03 Dec '15

03 Dec '15

Hello Corin, In your case i understand but I still don`t understand why force small clients to become LIR only for a /22 and in some case they will not use entirely, when we can do something and fast i think to loose or get in front of user eyes all bad behavior LIRs and of course all rest of us to help clients, and of course help RIPE to get back all that blocks that is use now only for sale. And if you see from a customer perspective you can see cause is too expensive sometimes to become LIR for a /22 and use only /23 or even all /22. This is not a good way. On 11/19/2015 10:35 PM, Corin Langosch wrote: > Hi Valentin, > > if you read the address policy working groups emails/ archives from the past weeks you can see I'm clearly against the > ipv4 business/ market place too. We are not a LIR to make money of IP space, we do real ISP/ hosting business for > several years now. We are short of IPV4 as many other LIRs are, especially those who only got a single /22. That's why > we had to ask some of our customer to become LIRs themselves (just as you were, as it sounds). As they don't need the > *whole* space immediately themselves, why not help them lease it to those who need it - not for astronomic prices but > reasonable ones? This way the space is not wasted and no ones ripped off - in contrast to the behaviour of many old LIRs > with space of /19, /18 up to /8 just laying around for years and just waiting for better prices. > > Sorry again and I hope you got the point. > > Best, > Corin > > __________________________________________________________________________ > Netskin GmbH · Trottenstrasse 89 · 8037 Zürich · Switzerland > http://www.netskin.com · fon +41 (0)32 513 40 24 · fax +41 (0)32 513 28 21 > > Am 19.11.2015 um 21:14 schrieb Valentin Panait: >

3 6

CFP: 19th IEEE Global Internet Symposium (GI 2016)
by Sandra Sendra 24 Nov '15

24 Nov '15

[Please accept our apologies if you receive multiple copies of this email] ######################################################################## CALL FOR PAPERs 19th IEEE Global Internet Symposium (GI 2016) In conjunction with IEEE INFOCOM 2016 San Francisco, CA, USA April 10-15, 2016 http://www.cs.helsinki.fi/group/eit-sdn/gi2016/ =========================================================== The Global Internet (GI) Symposium is the flagship event established and organized by the Internet Technical Committee (ITC), a joint committee of the IEEE Communications Society (ComSoc) and the Internet Society (ISOC). The 19th IEEE Global Internet Symposium will be collocated with IEEE Infocom 2016. All relevant dates, location, and travel information are available from the IEEE Infocom 2016 conference site:http://infocom2016.ieee-infocom.org/ The IEEE Global Internet Symposium aims to provide a top forum for researchers and practitioners to present and discuss advances in Internet related technologies. The focus of the symposium is on experimental systems and emerging future Internet technologies, and especially on scaling such systems to a global scale. Research on understanding Internet protocols, services, and applications at global scale is also encouraged. The Program Committee also welcomes position papers (which should be clearly marked as such). The topics of interest include, but are not limited to the following: Routing, switching, and addressing Resource management and quality of service Software defined networks and network programming Content delivery and management Energy awareness Next generation network architectures Distributed Internet applications including games, VoIP, and video conferencing Online social networking Peer To Peer networks Novel applications and new paradigms Internet measurement, modeling, and visualization Large scale network operation and performance monitoring Privacy and/or security issues on the Internet Anomaly, intrusion and attack detection Interface among networking, communications and information theory Applications of network science in communication networks Economic aspects of the Internet Important Dates: Paper submission: 22nd December 2015, 11:59 PM PST Notification of acceptance: 8th February 2016 Final manuscripts due: TBA. Symposium: TBA (around April 10-15, 2016) Submission Instructions: Submitted manuscripts must be formatted in standard IEEE camera ready format (doublecolumn,10pt font) and must be submitted via EDAS as PDF files (link https://edas.info/index.php?c=21740). The manuscripts must be no longer than 6 pages. The Program Committee reserves the right to not review papers that violate these formatting rules. Submitted papers must not have been previously published, or be under consideration for publication elsewhere. All submitted papers will be reviewed and judged on originality, technical correctness, relevance, and quality of presentation. All accepted papers must be presented at the symposium by one of the authors. Program Committee Chairs: Stefan Schmid (T-Labs & TU Berlin, Germany) Sasu Tarkoma (University of Helsinki, Finland) Technical Program Committee: Fred Baker (Cisco Systems, USA) Anat Bremler-Barr (IDC Herzliya, Israel) Ruben Cuevas Rumin (Universidad Carlos III de Madrid, Spain) Anja Feldmann (TU Berlin, Germany) Giancarlo Fortino (University of Calabria, Italy) Toru Hasegawa (Osaka University, Japan) James Kempf (Ericsson, USA) Kirill Kogan (IMDEA Networks Institute, Spain) Jaime Lloret Mauri (Polytechnic University of Valencia, Spain) Olaf Maennel (Tallinn University of Technology, Estonia) David Malone (Hamilton Institute, Ireland) Martin May (Technicolor, France) J�rg Ott (TU Munich, Germany) Colin Perkins (University of Glasgow, UK) George C. Polyzos (AUEB, Greece) Radia Perlman (EMC Corporation, USA) Ioannis Psaras (University College London, UK) Chen Qian (University of Kentucky, USA) Peter Reiher (UCLA, USA) Henning Schulzrinne (Columbia University, USA) Hiroshi Shigeno (Keio University, Japan) Michael Sirivianos (Cyprus University of Technology, Cyprus) Rade Stanojevic (Telefonica Research, Spain) Dan Wang (The Hong Kong Polytechnic University, Hong Kong) Gang Zhou (College of William and Mary, USA) ########################################################################

3 2

LIRs with good / bad behavior
by Valentin Panait 19 Nov '15

19 Nov '15

Hello everyone, I`m Valentin Panait a newcommer in RIPE Community I work in Internet business from 10 years plus but now i join to you in forced conditions. Now I`m glad that i`m a part of this community and i regret that i don`t do this early. What force me to become RIPE NCC Member/ LIR? I think you know. Bad behavior of some other LIR. HOW? Simple. Make me invoice for my ip`s with almost 300% plus for next year. In this manner i have 3 choises 1. Pay , but after that i was risk to shutdown the bussines. 2. Go to another LIR but i have to renumbering everything and lost almost all clients and ... shut down the bussines 3. Become LIR and accept HIS offer to transfer from him only a half of my ip`s to my LIR for free and he remain with the other half. I need to choose to become LIR. Consequences on my side: Renumberig all clients who was on 3 /22 Lost 62 clients who pay aroud 180 euros/month eatch 2 painful months for technicians, admins, client support team, and ofcourse CLIENTS. Pay aroud 2000 euro to become LIR. Consequences on his side: 3 /22 free and can put them on the BLACK MARKET on min 3euros/IP ... you can calculate how much money... only from one client. And after finish to sold all blocks he will go to Dubai for 50 years on our money. But now on black market the price could be up to 22$/IP THIS IS A GOOD BEHAVIOR? THIS IS WHAT RIPE COMMUNITY WHANT? THIS RESPECT THE RIPE COMMUNITY RULES AND PRINCIPLES? I THINK THE ANSWER IS NO. If someone can count how much IPv4 is for sale on BLACK MARKET today, we will see how much IPv4 is free and can be realocated. Now of course everyone will say: OK but what can we do about this? We have do somethig to stop this black market. I have few ideas and i`ll share with you. About LIR`s with bad behavior make a PUBLIC list of LIR`s and folowing of abuse reports that we receive from LIR`s clients, give a good or bad ratings. RIPE become regulatory authority for maximum price that a LIR can invoice a client for mainteinance ip resources / year. A client who has some IP`s from a bad LIR and he make proof of that with the invoice or proforma, can be tranfered for free to another LIR where he agree LIR conditions or has a better offer. I could be agree to get 10$/year/resource even if it is IP block or ASN and with a long time contract if client whant this. Why? Because i am not agree with what is happend now. I think that everyone hwo has a good behavior should not be afect by this rules. But we need to eliminate or stop who think that the privilege that they have because are old LIR`s and have more IPv4 give them the rights to make frome this a hudge bussines. I think the Internet bussines is to make money from services that is hosted on IP not from the IP`s. PS: A funny mail arrive that sound like this (where is dots i delete private informations): " Hi! We are a ..... LIR and have 5 /22 (=5x 1024) IPs for lease for a very reasonable price (< 1 €/ Ip/ month).The IPs are from the 185.0.0.0/8 block and have never been used before. They cannot be sold/ transferred as they are within the 24-month holding period. We are looking for a serious (no spam/ abuse), long-term cooperation (1+ year) only. If required, we could provide routing/ colocation/ server hosting too. I'm looking forward to your reply. Kind regards, ............." After my investigation He sad that have 5 /22 - WRONG on his Organisation Mainteiner and everything else that i found about him in RIPE database has only 1 IPv4 /22, 1 IPv6 /32, 2 ASN`s and a lot of mess on Inetnum`s how split that IPv4 /22. What happend with this guys? For this they become LIR to lease IP`s? I think in this case and could be more similar, we can create a WG to find this guys and report them someware. This is another place where we can find free block`s of IPv4. Let`s start to do somethig. Thank you very much that you lost your time to read this and i hope that all of you make a little time to reflect on my ideas. -- Best Regards, Valentin Panait System Administrator +40 741125871 www.ch-center.com ch-center ch-center Any disclosure, copying, distribution, posting or use of the contents of this information is prohibited and may be unlawful. This e-mail may contain proprietary or confidential information and is for the sole use of the intended recipient(s). Thank you.

1 0

2015-04 New Draft Documents and Impact Analysis Published (RIPE Resource Transfer Policies)
by Marco Schmidt 17 Nov '15

17 Nov '15

Dear colleagues, The draft documents for version 2.0 of the policy proposal 2015-04, "RIPE Resource Transfer Policies" have now been published, along with an impact analysis conducted by the RIPE NCC. The goal of this proposal is to create a single document with all relevant information regarding the transfer of Internet number resources. The key difference from version 1.0 is clarification in the policy text and policy summary regarding the 24-month holding period for scarce resources. You can find the full proposal and the impact analysis at: https://www.ripe.net/participate/policies/proposals/2015-04 And the draft documents at: https://www.ripe.net/participate/policies/proposals/2015-04/draft We encourage you to read the draft document and send any comments to <address-policy-wg(a)ripe.net> before 16 December 2015. Regards Marco Schmidt Policy Development Officer RIPE NCC

6 6

Revision of Last /8 Allocation Criteria
by David - ProfesionalHosting 17 Nov '15

17 Nov '15

OVERVIEW: Aims to allow LIRs to request an additional /22 IPv4 allocation from the RIPE NCC every 18 months. This would only be possible if the LIR has not transferred any IPv4 address space before. I support this measure. For us it is a big problem not to request more / 22, we are an ISP, and it does not seem fair to have to buy to get / 22 when others have to spare.

8 9

2015-05 New Policy Proposal (Revision of Last /8 Allocation Criteria)
by Marco Schmidt 17 Nov '15

17 Nov '15

Dear colleagues, A new RIPE Policy proposal, "Revision of Last /8 Allocation Criteria", is now available for discussion. The goal of this proposal is to allow LIRs to request an additional /22 IPv4 allocation from the RIPE NCC every 18 months. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2015-05 We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 18 November 2015. Regards Marco Schmidt Policy Development Officer RIPE NCC

46 81

Re: [address-policy-wg] Revision of Last /8 Allocation Criteria (Jim Reid)
by NOC ATOMOHOST 16 Nov '15

16 Nov '15

> Every LIR really has to accept that they have to wean themselves off IPv4 and have a serious approach to using IPv6. You’re going to have to do this at some point. You might as well do it now. IPv4 allocations from the RIRs are not going to last forever. Changing the address policy for everyone just so you can continue with an IPv4-only networking approach for a few more months is both unfair and unwise. Dear Jim, A lot of LIR's in the number of regions cannot allow themselves "serious approach to using IPv6" because of outdated infrustructure and lack of resources . We offer (see my previous mail) to let them grow and expand and let them opportunity to accumulate resources for update and renew their infrustructures. We expect that subsequently this can help such LIRs to deploy IPv6. Also worth mentioning that our adjustment restricts the possibilities to abuse policy changes by major LIRs who are already have the opportunity to deploy IPv6. -- Best regards, Igor Strelyaniy Network Operation Manager ATOMOHOST LLC email: noc(a)atomohost.com website: atomohost.com

2 2

Revision of Last /8 Allocation Criteria
by NOC ATOMOHOST 16 Nov '15

16 Nov '15

Hello, Me and my colleagues think that community should accept this proposal with an adjustment: ** 3. An equivalent of a /22 allocation can be requested every 18 months from the moment of the last allocation if the following conditions are met: 1. The LIR has not transferred any IPv4 address space out of its registry. 2. There is enough space in the free pool to perform the allocation Adjustment: 3. The LIR is not allocated more than equivalent of a /19 ** Adjustment reasoning: The last changes in IP Transfer policy (18 month transfer delay) positively influenced the fight against membership abuse. But we want to draw your attention to the fact that for now new members have virtually no space for further growth and development and are unable to compete with the old ones who were allocated much larger address space a long ago. The barrier and the prospect of a /19 prevents the old large members to abuse the changes and gives the new ones an opportunity to plan their growth for 12 years (on condition of 18 moth allocation delay), excluding transfers (in case if it is difficult to implement the transfer in a members service region). We belive that this policy changes with our adjustment will attract a new real and competitive members to community. -- Best regards, Igor Strelyaniy Network Operation Manager ATOMOHOST LLC email: noc(a)atomohost.com website: atomohost.com

1 0

2014-03 Policy Proposal Withdrawn (Remove Multihoming Requirement for AS Number Assignments)
by Marco Schmidt 15 Nov '15

15 Nov '15

Dear colleagues, The proposal 2014-03, "Remove Multihoming Requirement for AS Number Assignments" 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 solution which satisfied all parties. Regards, Marco Schmidt Policy Development Officer RIPE NCC

20 29

2014-03 New Draft Document and Impact Analysis Published (Remove Multihoming Requirement for AS Number Assignments)
by Marco Schmidt 07 Nov '15

07 Nov '15

Dear colleagues, The draft document for version 2.0 of the policy proposal 2014-03, "Remove Multihoming Requirement for AS Number Assignments" has now been published, along with an impact analysis conducted by the RIPE NCC. Some of the differences from version 1.0 include: - AS Numbers can now be assigned for any need that cannot be satisfied with an existing AS Number - The RIPE NCC's need evaluation has been removed - A limit of 1,000 AS Numbers per organisation has been added - There is now a requirement that 16-bit AS Numbers be multihomed after nine months - The requirement that the routing policy must be new and unique has been removed - Related wording adjustments in the summary and rationale of the proposal You can find the full proposal and the impact analysis at: https://www.ripe.net/ripe/policies/proposals/2014-03 And the draft document at: https://www.ripe.net/ripe/policies/proposals/2014-03/draft We encourage you to read the draft document text and send any comments to <address-policy-wg(a)ripe.net> before 22 January 2015. Regards Marco Schmidt Policy Development Officer RIPE NCC

16 41

RIPE 71 AP-WG Agenda v1
by Gert Doering 06 Nov '15

06 Nov '15

Hi APWG folks, RIPE meeting orga, below you can find a draft for the RIPE address policy WG meeting's agenda, which will take place in Bucharest in the following time slots: Wednesday, Nov 18, 09:00 - 10:30 Wednesday, Nov 18, 11:00 - 12:30 If you have anything else you want to see on the agenda, or if we need to change anything, please let us know. So far, the agenda is fairly light - if you have something you want to address, or that bothers you, let us know and we make room for you :-) The distribution of items to the two timeslot is somewhat subject to the time spent on discussion - but we'll try to stick to what's published. regards, Gert Doering, APWG chair ---------------------------------------------------------------------- Wednesday, 09:00-10:30 ---------------------------------------------------------------------- A. Administrative Matters (welcome, thanking the scribe, approving the minutes, etc.) C. Current Policy Topics - Marco Schmidt, NCC PDO - global policy overview "what's going on?" - common policy topics in all regions (end of IPv4, transfers, ...) - overview over concluded proposals in the RIPE region since RIPE70 2015-01 Alignment of Transfer Requirements for IPv4 Allocations 2015-02 Keep IPv6 PI When Requesting IPv6 Allocation 2015-03 Assessment Criteria for IPv6 Initial Allocation Size - brief overview over new proposals (if any) F. Discussion of open policy proposals 2014-03 Remove Multihoming Requirement for AS Number .. (Job Snijders - ...?) 2015-04 RIPE Resource Transfer Policies (Erik Bais) 2015-05 Revision of Last /8 Allocation Criteria (Radu-Adrian Feurdean, Elvis Velea) [some bits might get moved to "after coffee break" if we run out of time] ---------------------------------------------------------------------- Wednesday, 11:00-12:30 ---------------------------------------------------------------------- Welcome back H. Romania's jump to 1st place as exporter of IPs (Ciprian Nica) [30 min] presentation and discussion D. Feedback From NCC Registration Service - Ingrid Wijte (NCC RS) (+ discussion with the group) Y. Open Policy Hour "The Open Policy Hour (OPH) is a showcase for your policy ideas. If you have a policy proposal you'd like to debut, prior to formally submitting it, here is your opportunity." Z. AOB -- 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

1 0

Re: [address-policy-wg] 2015-05
by Dominik Nowacki 02 Nov '15

02 Nov '15

Hello, I think that if we are changing the policy in regards to allocations from the Last /8 we should make sure this is not abused. There are many LIRs setup solely for the purpose of getting an allocation from the last /8 to rent this space out. As this space is offered for a very low fee it is often abused and hence artificially increasing the IPv4 depletion. This should not be the case. I think the policy should allow for the subsequent allocations from the last /8, but only if the space is not only not transferred out of the LIR account in the period of 18 months AND the LIR was not renting the space from the last /8 to another entities within the last 18 months period (solely, not as part of another service). What do you think ? Kind Regards, Dominik Clouvider Limited

4 5

address-policy-wg
by Alessio Genova 31 Oct '15

31 Oct '15

Hello, we are working as Wireless Internet Service Provider in Italy, and we became a LIR at the beginning of 2013, requesting a /22. >From 2013 to today our customers have grown up to more than 5000. Today every time Policy requests us a log about some fraudulent behavior made from one of our customer by internet, we have to give them a lot of logs (Gbytes of logs) because of we cannot associate public IP addresses to every our customer. There are a lot of public IP addresses not used, and we are receiving a lot of proposals about selling IPs at 10€ / each . I think that RIPE should verify who really is using public IPs, or should introduce a way to avoid IPs market, giving IPs at who really needs them. Best Regards

12 15

R: address-policy-wg
by Alessio Genova 30 Oct '15

30 Oct '15

>It cannot be reiterated enough: The final /22 is a migration tool for IPv6. There is a large number of viable >solutions to use IPv6 as your main addressing scheme for a eyeball ISP, especially if you have started from >scratch only a few years ago. > >Instead of screaming for more regulation on a market that more or less works, I think that focusing on IPv6 >adoption should be the first order of business. > >Regards, > >--ck Who writes some sentence, surely knows that today IPv6 addressing in Italy is used only by Facebook, Google, Youtube and some other else, but most of sites are only reachable by IPv4. So, please, let me know how to migrate all our customers to IPv6 giving them access to the whole internet, as today, and we’ll make it. Vice versa I’m sure that RIPE should verify who really is using public IPs, or should introduce a way to avoid IPs market, giving IPs at who really needs them. Da: Alessio Genova [mailto:alessiogenova1@gmail.com] Inviato: giovedì 29 ottobre 2015 14:02 A: 'address-policy-wg(a)ripe.net' Oggetto: address-policy-wg Hello, we are working as Wireless Internet Service Provider in Italy, and we became a LIR at the beginning of 2013, requesting a /22. >From 2013 to today our customers have grown up to more than 5000. Today every time Policy requests us a log about some fraudulent behavior made from one of our customer by internet, we have to give them a lot of logs (Gbytes of logs) because of we cannot associate public IP addresses to every our customer. There are a lot of public IP addresses not used, and we are receiving a lot of proposals about selling IPs at 10€ / each . I think that RIPE should verify who really is using public IPs, or should introduce a way to avoid IPs market, giving IPs at who really needs them. Best Regards

4 3