From leo at vegoda.org Wed Oct 27 16:54:36 2021 From: leo at vegoda.org (Leo Vegoda) Date: Wed, 27 Oct 2021 07:54:36 -0700 Subject: [address-policy-wg] 1st Draft Agenda for Address Policy WG at RIPE 83 Message-ID: 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) From mschmidt at ripe.net Fri Oct 29 12:03:15 2021 From: mschmidt at ripe.net (Marco Schmidt) Date: Fri, 29 Oct 2021 12:03:15 +0200 Subject: [address-policy-wg] IPv6 Stockpiling Message-ID: 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 From gert at space.net Fri Oct 29 12:54:16 2021 From: gert at space.net (Gert Doering) Date: Fri, 29 Oct 2021 12:54:16 +0200 Subject: [address-policy-wg] IPv6 Stockpiling In-Reply-To: References: Message-ID: Hi, On Fri, Oct 29, 2021 at 12:03:15PM +0200, Marco Schmidt wrote: > There might be other options that this working group can consider and > discuss. I would be very interested to hear from a few LIRs that have more than 10 allocations what their reasoning is. I know at least one enterprise that has 3 LIR accounts for different parts of their business ("internal DC networks", "cloud stuff", "office networks") which are sufficiently disjoint that they effectively are 3 different companies, owned by the same mothership - so I do understand why some setups need/want "a handful" of allocations. I can also understand a setup where a multinational ISP is organized in a way so that every country network is served by a distinct LIR, so each can handle their local addressing needs as they find appropriate - and I'd also say that this is a good use of resources (and if the company decides that they want to merge all these LIRs into one umbrella account later, you'd end up with 10+ /29s). UUnet used to do that "back in the IPv4 days", and ended up with a big stack of red voting cards at AGM :-) So, these use cases I fully understand, and find them well within the goals of the IPv6 policy - make sure people have addresses to number their networks - make sure the RIPE NCC knows where these addresses are (registry) That said, I lack imagination why LIRs would need much higher numbers of /29, so it would be good to hear about the underlying reasoning - speculation won't adjust the policies in a positive way. *That* said, I'm not alarmed either, yet. 102 /29s is, in total, a /22 of IPv6 space. If this happens a few times per RIR, it won't make a noticeable dent in the available IPv6 space - which is, of course, the other aspect we need to take into account "will $this make us run out of address space in the next 50 years?". As of now, I'm more worried about deaggregation and routing table slots than I am about total address space burn rate. Gert Doering -- just a long time IPv6 policy geek -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From jordi.palet at consulintel.es Fri Oct 29 13:02:26 2021 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 29 Oct 2021 13:02:26 +0200 Subject: [address-policy-wg] IPv6 Stockpiling In-Reply-To: References: Message-ID: <7D136656-DFDC-49D2-B092-CCFFAD2E7FF2@consulintel.es> Hi Marco, all, I think we need to better understand the reasons/background on those multiple allocations. If the justification for a larger allocation is too "heavy" (I personally don't think so), we need to amend the language or the internal NCC procedure to facilitate larger allocations. I can also understand that some "bad" actors are actually doing this for stockpiling, but I fail to see how they could take advantage of that even in the medium/long term. I don't think they will be able to make business out of those addressed in the next hundred years or even more ... because I can't see how exhaustion can happen earlier. Definitively if they are trying to use this for other ISPs, it makes no sense, and it is bad for IPv6 deployment. So again, I'm convinced that we need to better understand the reasons why this is happening before taking concrete actions, unless I'm missing something else. Now, I've another question here. Once there are no more IPv4 addresses to give out ... there is any real business to allow "multiple LIRs" without a "stronger" justification? Because that will also resolve this problem ... Regards, Jordi @jordipalet ?El 29/10/21 12:03, "address-policy-wg en nombre de Marco Schmidt" escribi?: 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 ********************************************** 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. From raymond.jetten at elisa.fi Fri Oct 29 14:50:42 2021 From: raymond.jetten at elisa.fi (Jetten Raymond) Date: Fri, 29 Oct 2021 12:50:42 +0000 Subject: [address-policy-wg] IPv6 Stockpiling In-Reply-To: <7D136656-DFDC-49D2-B092-CCFFAD2E7FF2@consulintel.es> References: <7D136656-DFDC-49D2-B092-CCFFAD2E7FF2@consulintel.es> Message-ID: Hi Marco, All, One reason for a LIR to have multiple /29 is when a lir (ISP in this case) buys smaller operators and consolidates them. Since all of these blocks had some use before consolidation and its tedious to renumber.... I don?t see this as stockpiling, they will be even more in use in the future anyway, and we need to have enough use before being able to obtain more space... Rgds, Ray For Internal Use Only -----Original Message----- From: address-policy-wg On Behalf Of JORDI PALET MARTINEZ via address-policy-wg Sent: perjantai 29. lokakuuta 2021 14.02 To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] IPv6 Stockpiling Hi Marco, all, I think we need to better understand the reasons/background on those multiple allocations. If the justification for a larger allocation is too "heavy" (I personally don't think so), we need to amend the language or the internal NCC procedure to facilitate larger allocations. I can also understand that some "bad" actors are actually doing this for stockpiling, but I fail to see how they could take advantage of that even in the medium/long term. I don't think they will be able to make business out of those addressed in the next hundred years or even more ... because I can't see how exhaustion can happen earlier. Definitively if they are trying to use this for other ISPs, it makes no sense, and it is bad for IPv6 deployment. So again, I'm convinced that we need to better understand the reasons why this is happening before taking concrete actions, unless I'm missing something else. Now, I've another question here. Once there are no more IPv4 addresses to give out ... there is any real business to allow "multiple LIRs" without a "stronger" justification? Because that will also resolve this problem ... Regards, Jordi @jordipalet ?El 29/10/21 12:03, "address-policy-wg en nombre de Marco Schmidt" escribi?: 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 ********************************************** 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. From sander at steffann.nl Fri Oct 29 16:38:46 2021 From: sander at steffann.nl (Sander Steffann) Date: Fri, 29 Oct 2021 16:38:46 +0200 Subject: [address-policy-wg] IPv6 Stockpiling In-Reply-To: References: <7D136656-DFDC-49D2-B092-CCFFAD2E7FF2@consulintel.es> Message-ID: Hi, > One reason for a LIR to have multiple /29 is when a lir (ISP in this case) buys smaller operators and consolidates them. > Since all of these blocks had some use before consolidation and its tedious to renumber.... > > I don?t see this as stockpiling, they will be even more in use in the future anyway, and we need to have enough use before being able to obtain more space... 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 :) Sander From gert at space.net Fri Oct 29 17:03:46 2021 From: gert at space.net (Gert Doering) Date: Fri, 29 Oct 2021 17:03:46 +0200 Subject: [address-policy-wg] IPv6 Stockpiling In-Reply-To: References: <7D136656-DFDC-49D2-B092-CCFFAD2E7FF2@consulintel.es> Message-ID: 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From jake at brandergroup.net Fri Oct 29 19:59:41 2021 From: jake at brandergroup.net (Jake Brander) Date: Fri, 29 Oct 2021 17:59:41 +0000 Subject: [address-policy-wg] IPv6 Stockpiling In-Reply-To: References: <7D136656-DFDC-49D2-B092-CCFFAD2E7FF2@consulintel.es> Message-ID: <11322F29-5658-4874-B5C7-AEB43EA547CE@brandergroup.net> 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 at brandergroup.net | www.brandergroup.net Featured in Inc. Magazine & Ranked #6 on Inc. 5000 ? Read More ?On 10/29/21, 8:04 AM, "address-policy-wg on behalf of Gert Doering" 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 From raymond.jetten at elisa.fi Sun Oct 31 18:31:02 2021 From: raymond.jetten at elisa.fi (Jetten Raymond) Date: Sun, 31 Oct 2021 17:31:02 +0000 Subject: [address-policy-wg] IPv6 Stockpiling In-Reply-To: <11322F29-5658-4874-B5C7-AEB43EA547CE@brandergroup.net> References: <7D136656-DFDC-49D2-B092-CCFFAD2E7FF2@consulintel.es> <11322F29-5658-4874-B5C7-AEB43EA547CE@brandergroup.net> Message-ID: 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 ________________________________ From: address-policy-wg on behalf of Jake Brander Sent: Friday, October 29, 2021 8:59:41 PM To: Gert Doering ; Sander Steffann Cc: RIPE Address Policy Working Group 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 at brandergroup.net | www.brandergroup.net Featured in Inc. Magazine & Ranked #6 on Inc. 5000 ? Read More ?On 10/29/21, 8:04 AM, "address-policy-wg on behalf of Gert Doering" 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: