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

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