November 2021 - address-policy-wg

Review of IPv6 Policy Goals
by Leo Vegoda 29 Nov '21

29 Nov '21

Dear Address Policy WG, This is the promised message to begin a review of the IPv6 Policy Goals, following the introduction of the subject during our session at RIPE 83. Several people have already spoken up and stated their intent to participate. We’d like to invite everyone interested to respond to the questions below, so we can gauge the WG’s interest in this subject and plan the next steps on that basis. For those who were unable to attend the session, the slides can be found here: https://ripe83.ripe.net/wp-content/uploads/presentations/37-RIPE-83-APWG-IP… And the video recording is here: https://ripe83.ripe.net/archives/video/644 You can find the goals in full in our current IPv6 policy document: https://www.ripe.net/publications/docs/ripe-738#3 There are two main motivations for this discussion. Firstly, the world around us has changed over the 20 years since the goals were integrated into the policy. Secondly, the RIPE NCC is guided by these goals when it implements policy. If there is some degree of executive discretion on how to implement a policy then the RIPE NCC's people will do their best to implement a policy in a way that achieves the overall policy goals. This means that any changes to the IPv6 policy goals could have two impacts: 1) The RIPE NCC might adjust its implementation of one or more existing policies so that those implementations work towards the updated goals. 2) People in the RIPE community might identify a need for policy changes and initiate a policy discussion. The specific questions we'd like to ask the community to discuss are: A) Are all of the goals still relevant? B) Should the priority or wording of goals change? C) Does our changing world require new goals? Responses in support of keeping the goals unchanged are just as welcome as responses indicating that a change is necessary. We look forward to reading your thoughts. Kind regards, Leo Vegoda for the Address Policy WG co-chairs

1 0

Re: [address-policy-wg] IPv6 Stockpiling
by Adrian Bolster 29 Nov '21

29 Nov '21

Good day to you! All important information you asked for you can find in the document via the link below. 1)dancetvshow.com/laboriosamporro/quiadolorum-4312207 2)meralawfirm.com/inventoreodit/sedeos-4312207 The stats on adoption are far more interesting when you look at them by country: https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-ad… That 34% is concentrated in a quite small number of countries -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains https://www.blacknight.com/ https://blacknight.blog/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Personal blog: https://michele.blog/ Some thoughts: https://ceo.hosting/ ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845 From: address-policy-wg <address-policy-wg-bounces(a)ripe.net> on behalf of Jetten Raymond <raymond.jetten(a)elisa.fi> Date: Sunday, 31 October 2021 at 17:31 To: Jake Brander <jake(a)brandergroup.net>, Gert Doering <gert(a)space.net>, Sander Steffann <sander(a)steffann.nl> Cc: RIPE Address Policy Working Group <address-policy-wg(a)ripe.net> Subject: Re: [address-policy-wg] IPv6 Stockpiling [EXTERNAL EMAIL] Please use caution when opening attachments from unrecognised sources. Hi Jake, Thanks for your comment. According to https://www.google.com/intl/en/ipv6/statistics.html about 34 % of the internet users that access google use IPv6, and i fully agree that its not enough. In case you have some ideas on how to improve this miserable amount i welcome you to the IPv6 working group mailing list and share your thoughts.. Best Regards, Ray One of the IPv6 wg co chairs https://www.ripe.net/participate/ripe/wg/active-wg/ipv6 Hanki Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: address-policy-wg <address-policy-wg-bounces(a)ripe.net> on behalf of Jake Brander <jake(a)brandergroup.net> Sent: Friday, October 29, 2021 8:59:41 PM To: Gert Doering <gert(a)space.net>; Sander Steffann <sander(a)steffann.nl> Cc: RIPE Address Policy Working Group <address-policy-wg(a)ripe.net> Subject: Re: [address-policy-wg] IPv6 Stockpiling It seems like stock piling IPv6 is similar that what occurred with IPv4 a long time ago. The only difference is nodbody is using IPv6 and there is an abundance of it available.. How do we get people to actually use it? All the best, Jake Brander President | Brander Group Inc. O: (702) 560-5616 x700 | M: (310) 595-6266 jake(a)brandergroup.net | www.brandergroup.net<http://www.brandergroup.net> <http://www.brandergroup.net> Featured in Inc. Magazine & Ranked #6 on Inc. 5000 ? Read More <https://brandergroup.net/2021/08/brander-group-ranked-6-on-inc-5000-in-2021/> On 10/29/21, 8:04 AM, "address-policy-wg on behalf of Gert Doering" <address-policy-wg-bounces(a)ripe.net on behalf of gert(a)space.net> wrote: Hi, On Fri, Oct 29, 2021 at 04:38:46PM +0200, Sander Steffann wrote: > If this is indeed the reason I see no problem with it. That's just operational reality. > > If there is some misunderstanding causing LIRs to accumulate many IPv6 allocations then we can look at better education. > And if there is some malign reason for it, then we can look at changing the policy. > > I think we need to understand the symptoms better to be able work on the cure :) This! Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 For Internal Use Only

1 1

do we need a policy for avoiding "multiple unjustified LIRs"?
by JORDI PALET MARTINEZ 24 Nov '21

24 Nov '21

Hi all, After looking at the video from Marco, today presentation/discussion and the recent discussions on this, as I just mention, should we work in a policy proposal to amend the internal procedure so the justification for additional LIRs is stronger? I understand many cases for the need of an additional LIR, but doing valid for *any artificial case* is not good. Any though on that? Possible ideas about how we define the border line? As usual, I'm happy to work on this myself, or together with other folks. Regards, Jordi @jordipalet ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com 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.

4 5

Suggestion to replace IPv4 waiting list with auctions
by Wolfgang Zenker 24 Nov '21

24 Nov '21

Greetings, in todays WG session Marco Schmidt pointed out that more than half of the /24s allocated from the waiting list pool go to members with multiple LIRs. The number of newly created LIRs eligible for a /24 has increased a lot in recent months, to the point where requests can no longer be filled from the available pool but new LIRs have to wait for blocks coming out of quarantine. This change appears to be due to market value for IPv4 blocks being now significantly larger than the cost for creating a new LIR and maintaining it for the two year holding period. The result of this is that newcomers have no easy access to a first IPv4 block but have to wait in line together with multi-LIR address hoarders, defeating the purpose of the waiting list policy. I suggest to replace the waiting list with the following system: - /24s becoming available are put to an auction. - every interested member organisation (NOT: LIR) can make a bid of an amount that is not visible to the other bidders. - highest bid wins. Expected result would be less requests from address hoarders because they could get address blocks for a similar price on the open market without the additional overhead of creating a new member. Newcomers on the other hand would have to become members to be able to hold addresses in the first place, and can use the auction to get access to a properly quarantined address block to start their business. Regards, Wolfgang Zenker -- punkt.de GmbH Tel. +49 721 9109-500 Fax: -100 .infrastructure info(a)punkt.de https://infrastructure.punkt.de/ Kaiserallee 13a CEO: Jürgen Egeling, Daniel Lienert, Fabian Stein D-76133 Karlsruhe AG Mannheim HRB 108285

8 13

IPv6 Stockpiling
by James Kennedy 24 Nov '21

24 Nov '21

[changed mail client alias\author to my name, apologies for duplication] Hi, Re: 'who does IPv6 hoarding really hurt' or 'what's the danger', we should learn from some very harsh real-life lessons that happened with IPv4 stockpiling. - when IPv4 was plentiful, a number of RIPE members we able to hoard vast volumes of IPv4 and distribute large IPv4 network prefixes (e.g. full /18s) to their customers but provide little to no technical services (became de facto local RIRs) - this was attractive to their customers at the time - often network operators - because the RIPE members would lease the address space for a much lower price than a RIPE NCC membership fee - as their customers became increasingly dependant on those IPv4 network prefixes over time to run their operations, the RIPE members abused their power and raised the lease costs to absolute extortionate and unaffordable amounts - often to sell the parent allocation on the IPv4 market This is in addition to conflicting with RIPE IPv6 goals and policy, and reducing the RIPE NCC's ability to check and verify that the address space is being used in line with RIPE IPv6 goals and policy. Do we really want to sleepwalk into a similar situation with IPv6? If not, how can we proactively safeguard IPv6 from such abuse while ensuring easy access to IPv6 for real deployments? Change IPv6 transfer policy, and/or lower the RIPE NCC membership fee (e.g. a cheaper IPv6-only membership category)? Regards, James apwg co-chair

2 1

Assignments from a /24 allocation
by denis walker 24 Nov '21

24 Nov '21

Colleagues The issue came up again today at the AP-WG session at RIPE-83 about making assignments from a /24 allocation. People are forced to create two 'artificial' /25 assignments. Again this is used as one argument against having to register assignments in the RIPE Database. Regardless of the bigger picture about registering assignments, there is a simple solution to the /24 allocation issue. Make the "status:" attribute multiple. Then this /24 INETNUM object can have: status: ALLOCATED PA status: ASSIGNED PA Business rules can restrict the use of multiple status to very specific use cases. Maybe only allow a second status of 'ASSIGNED PA' in an object with status 'ALLOCATED PA'. The normal rules then apply to an assignment, so there can be no more specifics. Then any allocation of any size can be assigned in its entirety without having to create more specific pseudo assignment objects. Business rules could also allow this option for 'SUB-ALLOCATED PA'. cheers denis co-chair DB-WG

2 1

Excellent Presnetations & Videos, how can I help?
by Karla Wagner 23 Nov '21

23 Nov '21

Good Morning! The material presented hung together well, and the speakers asked excellent questions. Thank you for that !! Having a keen interest (and a course or two) in public policy, I'd be interested in helping out. Please let me know. (The speaker indicated that help was needed, and to refer to the mailing lists.) Met vriendelijke groet, Karla Verzonden door ProtonMail Secure Email.

2 1

IPv6 Stockpiling
by _ _ 23 Nov '21

23 Nov '21

Hi, Re: 'who does IPv6 hoarding really hurt' or 'what's the danger', we should learn from some very harsh real-life lessons that happened with IPv4 stockpiling. - when IPv4 was plentiful, a number of RIPE members we able to hoard vast volumes of IPv4 and distribute large IPv4 network prefixes (e.g. full /18s) to their customers but provide little to no technical services (became de facto local RIRs) - this was attractive to their customers at the time - often network operators - because the RIPE members would lease the address space for a much lower price than a RIPE NCC membership fee - as their customers became increasingly dependant on those IPv4 network prefixes over time to run their operations, the RIPE members abused their power and raised the lease costs to absolute extortionate and unaffordable amounts - often to sell the parent allocation on the IPv4 market This is in addition to conflicting with RIPE IPv6 goals and policy, and reducing the RIPE NCC's ability to check and verify that the address space is being used in line with RIPE IPv6 goals and policy. Do we really want to sleepwalk into a similar situation with IPv6? If not, how can we proactively safeguard IPv6 from such abuse while ensuring easy access to IPv6 for real deployments? Change IPv6 transfer policy, and/or lower the RIPE NCC membership fee (e.g. a cheaper IPv6-only membership category)? Regards, James apwg co-chair

1 0

1st Draft Agenda for Address Policy WG at RIPE 83
by Leo Vegoda 21 Nov '21

21 Nov '21

Dear Address Policy WG, Here is the first draft agenda for RIPE 83's Address Policy WG. We want to give as much time as possible to discussion. For this reason, we are continuing with the concept of pre-publishing videos and slides for report items on the agenda. This way, people can review the presentations at their leisure, allowing us to dedicate more time to answering questions and discussing issues with each other. You will be able to watch pre-recorded presentations and review slides from Monday, 15 November. They will be available on https://ripe83.ripe.net and we will send a note linking to the relevant page. Kind regards, Leo Vegoda for the Address Policy WG co-Chairs A. Administrative Matters (5 mins) Chairs Welcome, thanking the scribe, approving the minutes, etc. B. ASO AC Report Summary and Questions (10 mins) This will be pre-recorded and published a week ahead. A 2 slide recap will be presented live before questions are taken. James Kennedy / Nurani Nimpuno / Hervé Clement C. NRO NC/ASO AC Candidate Introductions (10 mins) This will be pre-recorded and published a week ahead. A 2 slide recap will be presented live before questions are taken. Ulka Athale, Sr. Communications Officer, RIPE NCC D. Q&A on Current Policy Topics (15 mins) This will be pre-recorded and published a week ahead. A 2 slide recap will be presented live before questions are taken. Angela Dall'Ara, Policy Officer, RIPE NCC E. Q&A on Feedback from the RIPE NCC Registry Services (15 mins) This will be pre-recorded and published a week ahead. A 2 slide recap will be presented live before questions are taken. Marco Schmidt, Registry Services, RIPE NCC F. RIPE Database Requirements TF (10 mins) This will be pre-recorded and published a week ahead. A 2 slide recap will be presented live before questions are taken. James Kennedy G. Break (5 mins) H. Review of RIPE IPv6 Policy Goals (20 mins)

1 2

IPv6 Stockpiling
by Marco Schmidt 04 Nov '21

04 Nov '21

Dear colleagues, During RIPE 82, we provided you with an update on our observation of IPv6 stockpiling [1]. Based on the feedback we received and in preparation for the coming RIPE meeting, we would like to give you another update on that issue. According to the IPv6 Address Allocation and Assignment Policy, an LIR can receive up to a /29 IPv6 allocation without needing to supply any additional information. The RIPE community considered this size sufficient for most organisations for long-term IPv6 deployment. Additionally, LIRs may qualify allocations greater than /29 by submitting documentation that reasonably justifies this request [2]. However, over the past few years we have noticed that some organisations are collecting multiple IPv6 allocations in ways that are permitted by current RIPE policies but might conflict with the above-mentioned intent of the IPv6 policy. For example, it is possible for a single RIPE NCC member to receive a /29 allocation for each of the multiple LIR accounts that it holds. This is the result of a policy change in 2018 [3]. LIRs can also receive multiple IPv6 allocations via policy transfers without needing any further justification. However, when the IPv6 transfer policy was discussed in 2014, it was assumed that there wouldn't be an active transfer market [4]. We have gathered data showing the significant development of the collection of IPv6: - Almost 700 IPv6 allocations have been transferred in 2021 so far (and there have been more than 3,900 transfers since policy implementation in 2015) - About 60% all IPv6 allocations ever handed out by the RIPE NCC are now held as multiple allocations - In the last three months, more than 75% of all new allocations were given to members that already hold at least one IPv6 allocation - More than 1,500 members hold multiple IPv6 allocations, exceeding the size /29 - Almost 100 members hold more than 10 IPv6 allocations (the maximum is 102 IPv6 allocations held by one member) It is the RIPE NCC’s understanding that some of these situations are within the intent of previous policy changes, for example, to avoid renumbering of deployed IPv6 networks during holdership changes, or if a large company has multiple network departments that prefer to manage their own allocation. However, the huge volume indicates that most are for other reasons. While members can collect multiple IPv6 allocations without evaluation by the RIPE NCC, we still were able to gather some feedback how members plan to use their allocations. Many members simply stockpile them for an undefined future use, others plan to use them for activities which temporarily require a vast amount of IPs, and some plan to offer IPv6 on a large scale to other ISPs in their country. We believe that this situation could create several issues: - IPv6 might be deployed in conflict with RIPE policies, underlying RFCs and other best practices, resulting in challenges to that IPv6 deployment once the policy violation is discovered during an audit - There could be a negative impact on the quality of the registry if large parts of allocations were given to third parties without clear registration requirements - The policy requirement to justify larger IPv6 allocations would then be rendered useless If you agree that this is a problem, we would like to initiate a discussion in this Working Group about possible solutions. We see at least two potential paths forward. Firstly, if the Working Group believes that this trend is an indication of a widespread need for IPv6 address space larger than /29, then the requirement for justification could perhaps be adjusted for a larger allocation size. Members could then more easily get the address space they need, but as an aggregated block. Stockpiling would still be possible under this potential policy change, in fact on an even bigger scale. Secondly, if the Working Group believes that this trend is in conflict with the original intent of the IPv6 policy, adjustments to the policy can be proposed that give the RIPE NCC a stronger mandate to enforce it. One challenge here would be defining what IPv6 usages are considered within or outside of the intent of the policy and how to ensure better oversight without too much impact on IPv6 deployment. There might be other options that this working group can consider and discuss. If required, the RIPE NCC can provide additional information for this discussion. Kind regards, Marco Schmidt Registry Services Assistant Manager RIPE NCC [1] https://ripe82.ripe.net/presentations/7-RIPE82-Feeback-from-RS.pdf from slide 9 [2] https://www.ripe.net/publications/docs/ripe-738#initial_allocation [3] https://www.ripe.net/participate/policies/proposals/2018-01 [4] https://www.ripe.net/participate/policies/proposals/2014-12

8 9