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

New on RIPE Labs: So Long Last /8 and Thanks For All the Allocations
by Mirjam Kuehne 28 Aug '19

28 Aug '19

Dear colleagues, On 17 April 2018, we allocated the last available block of 1,024 addresses in 185/8 - the last /8 we received from IANA back in 2011. This article on RIPE Labs looks at how this address space was allocated and how it is used today: https://labs.ripe.net/Members/wilhelm/so-long-last-8-and-thanks-for-all-the… It's important to keep in mind that while 185/8 is finished, we still have around nine million recovered IPv4 addresses in our available pool. Under current policy and growth rates, we expect these to last a further two years. Kind regards, Mirjam Kühne RIPE NCC

3 2

2018-01 Review Phase (Organisation-LIR Clarification in IPv6 Policy)
by Marco Schmidt 12 Jun '18

12 Jun '18

Dear colleagues, Policy proposal 2018-01, "Organisation-LIR Clarification in IPv6 Policy" is now in the Review Phase. This proposal aims to clarify the wording used in ripe-699 regarding terms such as "organisation" and "LIR". The proposal has been updated following the last round of discussion and is now at version v2.0. Some of the differences from version v1.0 include: - Clarifies when the subsequent allocation policy applies - Fixing some typos The RIPE NCC has prepared an impact analysis on this latest proposal version to support the community’s discussion. You can find the full proposal and impact analysis at: https://www.ripe.net/participate/policies/proposals/2018-01 And the draft documents at: https://www.ripe.net/participate/policies/proposals/2018-01/draft As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussing the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document. At the end of the Review Phase, the WG Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. We encourage you to read the proposal, impact analysis and draft document and send any comments to <address-policy-wg(a)ripe.net> before 1 June 2018. Kind regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

9 10

proposal to remove IPv6 PI
by JORDI PALET MARTINEZ 21 May '18

21 May '18

Hi all, For those that haven't been in the meeting, the slides are available at https://ripe76.ripe.net/presentations/97-RIPE-2018-05-v1.pdf I believe we have several problems that my proposal is trying to fix. 1) See my previous email on the clarification of IPv6 PI sub-assignments. Is not just a matter of IPv6, but also IPv4. This is an alternative solution (at least of the IPv6 part - we could do the same for IPv4 of course and also remove IPv4 PI). 2) It was clear in the meeting, as we *all* know, that many folks in the community (and not only in this region) are abusing the policy and they actually use end-user space (PI policies) to *assign* (call it sub-assign if you prefer it), to third parties. 3) It may be the case that this happens because the fee structure. An LIR, currently, pays 1.400 Euros per year (plus one-time setup-fee of 2.000 Euros). And end-user just pay 50 Euros per resource assignment. So, it makes sense to just pay for 50 Euros, and then you may be providing services using NAT+CGN (in the case of IPv4) or a single /64 to each subscriber in the case of IPv6. It is broken, of course, but people do that. 4) The fee scheme is somehow responsible of that as well, as there is in my opinion, unfairness. A big ISP having an IPv6 /20, or /24 or /29 or /32 is paying always the same. This is the only region that have a "flat" rate. 5) We could fix the point above, auditing every end-user. But we could also fix it in a better way by: a) A policy change in the line the one I've proposed (see the slides and the links for a diff) b) Having a single LIR contract, instead of LIR and end-user c) This may be (as an option), also become a way to make a price scheme which is proportional to the amount of resources allocated. Note that we don't need to change the fee scheme, but it is an opportunity for taking a look into that. It may be perfectly possible to keep the cost of end-users as 50 Euros (for a single /48, for example), but having a single contract. I know perfectly that fees are not "policy", however only if we address that we can do correctly the policy. A demonstration of that: When I proposed the IPv6 PI and it reached consensus, it was needed to create the "end-user" contract and the corresponding fee, so is something that we have done before. I know that the proposed text may be very imperfect, for example the usage of "ISPs", but this is not the key now, there are for sure several alternatives to that. For example, we could just differentiate both cases with "LIR that do subsequent distributions initially qualify for /32 up to /29 etc. LIRs that do not do subsequent distributions initially qualify for a /48 for each end-site". So please, don't consider specific text at this point of the discussion. And last, but not least, repeating myself, we could do this just for IPv6, or also work in parallel in a policy proposal for IPv4 PI removal as well. This will be probably the best choice, so we can let the NCC to have a simplified policy, a single contract and consequently less overhead: Simplification for everyone. Thoughts? Regards, Jordi ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

16 50

2018-02 Assignment Clarification in IPv6 Policy - comments from today meeting
by JORDI PALET MARTINEZ 18 May '18

18 May '18

Hi all, I've been asked to state what is the problem. I think it was clear in my slides, but anyway, here we go with all the problems I see: 1) The current policy text says "Providing another entity with separate addresses (not prefixes)". To me this is inconsistent addresses instead of an address vs not-prefixes. 2) If the end-device need a /64 instead of a single address, as per RFC8273, then it is breaking the actual policy. 3) If we allow sub-assignments, what is then the difference in between IPv6 PA and PI ? So, I think it is clear we have not just one problem? Now, if we want to go further. Do we have the same problem with IPv4 if, for example a university, instead of using NAT, they also sub-assign public IPv4 addresses to students? Inputs? Regards, Jordi ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

2 4

2018-01 New Policy Proposal (Organisation-LIR Clarification in IPv6 Policy)
by Marco Schmidt 16 May '18

16 May '18

Dear colleagues, A new RIPE Policy proposal, 2018-01, "Organisation-LIR Clarification in IPv6 Policy" is now available for discussion. This proposal aims to clarify the wording used in ripe-684 regarding terms such as "organisation" and "LIR". You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2018-01 As per the RIPE Policy Development Process (PDP), the purpose of this four week Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposers, with the agreement of the WG Chairs, will decide how to proceed with the proposal. We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 23 March 2018. Regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

11 11

2018-01 Organisation-LIR Clarification in IPv6 Policy - comments from today meeting
by JORDI PALET MARTINEZ 16 May '18

16 May '18

Hi all, I tried to find the "mismatch" that Peter mention today in the meeting about this proposal text, however was unable to. So, if Peter or somebody else can point to anything more specific, the authors will be happy to provide thougths for alternatives to the mismatching text. Thanks! Regards, Jordi ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

1 0

FW: WG chair change
by Erik Bais 12 May '18

12 May '18

Hi Gert, Sander & AP-WG members, Thank you for the email and I would like to formally put my name in the hat. For those that don't know me personally, my name is Erik Bais, Dutch, I'm 45, married for 16 year with my wife Wilhelmina and we have 2 sons. I'm the owner of a Dutch ISP named A2B Internet and I'm one of the co-founders of the IPv4 broker : Prefix Broker. I've lived most of my life in The Netherlands and as a family, we lived for almost a year in the UAE (Dubai) in 2008/2009, when I worked for a US based system integrator and I've worked in Germany for a US based company in the 90's for a year. I have a been working in the ISP community since the 2000. And started A2B Internet in 2010 in The Netherlands. In our work as a connectivity ISP, we started to request AS numbers and IP space for customers in order to get them migrated to our network and while doing so, we noticed some things that needed improvement in the AP policies. That is how it all got started ... I've been the author of the following proposals that have been accepted by the community: https://www.ripe.net/participate/policies/proposals/2011-02 : Removal of multihomed requirement for IPv6 PI # co-author together with Jordi https://www.ripe.net/participate/policies/proposals/2013-04 : Resource Certification for non-RIPE NCC Members # Services WG - allowing PI space holders and Legacy space holders the option for RPKI certification. https://www.ripe.net/participate/policies/proposals/2014-02 : Allow IPv4 PI transfer https://www.ripe.net/participate/policies/proposals/2014-12 : Allow IPv6 Transfers https://www.ripe.net/participate/policies/proposals/2014-13 : Allow AS Number Transfers https://www.ripe.net/participate/policies/proposals/2015-04 : RIPE Resource Transfer Policies And I've been quite active on the discussions on the mailinglist and in the GM's. Besides the various presentations about the policies, I've also done some presentations in the plenary of the RIPE meetings and different WG's about various topics.. Examples are: https://ripe72.ripe.net/archives/video/116/ : Naughty Port project about a different way of making a peering decision based on Network Naughty-ness using a rating system against DDOS's. https://ripe74.ripe.net/archives/video/119/ : IRR Filtering at IXP Route Servers https://ripe75.ripe.net/archives/video/165/ : Pre-Transfer Clean-Up of Abused Prefixes I really like the RIPE community and as an active policy proposer, I think I can say that I have been around the block on the PDP and can work with the sometimes harsh way of communication that a co-chair role has need to deal with in the heat of some discussions. I understand what it requires in effort from time to time and as I'm living in the Netherlands, it makes it easy to visit the Amsterdam RIPE office for me if needed. I hope that the community appreciates the transparent way of communicating and knowledge sharing that I like and that I will be selected as the co-chair for the AP-WG. Regards, Erik Bais

2 1

IP/ASNs for Governments BoF
by Iljitsch van Beijnum 07 May '18

07 May '18

Hi all, I'd like to call your attention to a BoF that was added to the schedule last week: IP/ASNs for Governments Iljitsch van Beijnum, Logius, Dutch Ministry of the Interior and Kingdom Relations The purpose of this BoF is to discuss the needs of government and large organisations when it comes to IPv6 address allocations and ASN assignments. We will cover the ways in which RIPE Policies could be changed to better support these large entities that are often comprised of many independent sub-organisations with their own connections to the Internet. Please also note my (relatively) new affiliation. :-) However, I'm using my old email address here to avoid even more spam. The idea behind this BoF is that governments (and some other very large organizations) find it useful to number all their sub-organizations from a single large block, but these sub-organizations connect to the internet independently. We've done this with the Dutch government-wide IPv6 numbering plan, which provides IPv6 addresses to the national government, but also provinces and cities. In Germany there's also a similar IPv6 numbering plan. However, the RIPE policies don't fit this use case very well. We believe it would be useful to start a discussion with the community to see how this is best addressed. There's also some issues surrounding the use of public AS numbers for very large private networks. I haven't been on this list for a number of years, so if all of this has been discussed recently, my apologies. The full BoF proposal is here: https://ripe76.ripe.net/wp-content/uploads/submissions/RIPE-76-IP-ASNs-for-… <https://ripe76.ripe.net/wp-content/uploads/submissions/RIPE-76-IP-ASNs-for-…> Iljitsch van Beijnum

2 2

WG chair change
by Gert Doering 07 May '18

07 May '18

Dear AP WG, as announced, my co-chairs of amazingly many years, Sander Steffann, will be stepping down as a WG chair at the next RIPE meeting. Our WG chair selection policy is described here: https://www.ripe.net/participate/ripe/wg/ap https://www.ripe.net/participate/ripe/wg/ap/address-policy-wg-chair-selecti… according to this, we'll spend a few minutes at the next APWG session in Marseilles to select a new co-chair. To avoid lengthy rounds of introduction at the meeting, I want to ask for volunteers here on the list - please step forward if you want to take up this work, and introduce yourself on why you think you're a good candidate and what your plans for the WG are for the next two years (or longer). A short recap of the WG chairs duties: - chair the APWG session at the RIPE meetings (so generally it is expected that both co-chairs can attend most RIPE meetings and feel halfway confident talking on stage and moderate a discussion) - read - and if necessary, moderate - the APWG mailing list (thus, fluency in written English is necessary, and while discussions are going on, some amount time spent at least every few days) - help policy proposers bring their policy proposal through the PDP (answering questions, helping with the wording of proposed text, spending some time discussing 'next steps' for a proposal) - judge consensus at the end of discussion and review phases according to our policy development process (usually done by both co-chairs together, unless a conflict of interest appears) - help shape the format of RIPE meetings together with all the other WG chairs and the RIPE PC - by mailing list and by attending the "WG chair lunch" on RIPE meeting Thursdays - see also: https://www.ripe.net/publications/docs/ripe-692 A definite plus for an APWG chair is "operational experience with these pesky numbers" - either by operating the address management side (LIR) of an Internet Service Provider or Enterprise network, or by being an address broker, etc. Sander and I have spoken to a few of you who would make good chairs already - but ultimately, it's up the working group to decide. So even if you have spoken to us privately before, please speak up now. So, come forward, dear candidates and make yourself known! :-) Gert Doering -- APWG chair -- 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 5

WG Chair selection
by Paul Hoogsteder 06 May '18

06 May '18

Hello AP-WG, I don't think I've seen any support for either candidate for the position of WG chair on the list yet. I think Erik Bais is more than qualified for such a position, he's been active in the RIPE community and this working group for years and has made many valuable contributions. +many for Erik! Best regards, Paul Hoogsteder Meanie AS31019 Breedband Delft AS34108

13 12