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

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