Dear IPv6 working group,
The draft minutes for the IPv6 WG session at RIPE 91 are ready, A very big thank you to the scribe Kjerstin Burdiek for doing them. Please take a look and let us know if you would like any changes. If there are no comments, they will be published on the website on Friday, 28 November. Date: Thursday, 23 October 09:00 - 10:30 (UTC+3) Chairs: Christian Seitz, Raymond Jetten, Wolfgang Tremmel Scribe: Kjerstin Burdiek Status: Draft View the recordings View the stenography transcript View the chat logs 1. Welcome and announcement of the new co-chair The presentation is available at: https://ripe91.ripe.net/programme/meeting-plan/sessions/37/RTKFBS/ Co-chair Christian Seitz opened the session and introduced the agenda. The minutes from RIPE 90 were approved. Co-chair Raymond Jetten's term had ended, and Wolfgang Tremmel was selected as the new co-chair. However, co-chair Nico Schotellius had resigned, so Raymond Jetten would take over his term until RIPE 94. 2. IPv6: What does it cost to do nothing? Dmitry Melnik, RIPE NCC The presentation is available at: https://ripe91.ripe.net/programme/meeting-plan/sessions/37/8YZNF9/ Dmitry explained the long-term costs of not implementing IPv6. He noted that the average IPv6 adoption rate worldwide was about 42%. He explained how a number of organisations were investing in NAT, which was only a temporary solution to the IPv4 shortage. Dmitry pointed out that it made no sense to try to solve the IPv4 shortage when there was more than enough IPv6. Some of the costs from not switching to IPv6 included leasing IPv4, operational costs and the equipment needed for NAT. Altogether, these extra costs compared to dual-stack added up to an additional $1.2 - 2.1 million spent over 5 years. Benedikt Stockebrand, Stepladder IT Training+Consulting GmbH, said that although Dmitry had shown the same traffic growth for IPv4 and IPv6, IPv6 was really growing faster. So IPv4 had an even less favourable outlook than what Dmitry had presented, and the actual cost was higher. Dmitry said he had calculated using IPv4 through a NAT system. Benedikt said he understood and that if someone did not do dual-stack, it would cost even more money to stay with IPv4. Dmitry thanked him for his comment. Yannis Nikolopoulos, Orizon Telecom, said the time was long past to convince people to do dual-stack. Most existing operators already did this. Instead, it was time to convince new operators to get IPv6, but not through dual-stack. Dmitry thanked him and said his calculation would also be true for cases like migration to IPv6-mostly. Dave Phelan, APNIC, said that in his region, the type of network deployed depended on the type of users and therefore the type of traffic. For residential users, who mainly used content, networks were usually IPv6. Enterprises were the problem here because they did not want to deploy IPv6. Dmitry said this presentation was more for medium to large operators. He agreed that IPv6 deployment was needed for content operators, and the community needed to engage them and help with enterprise networks. Sebastian Becker, Deutsche Telekom AG, agreed with the points about enterprise. He then mentioned that smart devices in homes often could not do IPv6. So even if operators fully deployed IPv6, there would still be IPv4 traffic as long as people used these devices. He encouraged people to stop buying them. Gilles Massen, Fondation Restena, said the industry was weak on teaching, as students often learned primarily about IPv4. He said operators should try to convince teachers to update their courses. Saiidnajib Saidislomzoda, CJSC Babilon-Mobile, asked if investments in IPv6 could be seen not only as a technical upgrade but as a step toward financial sustainability for network operators. Saiidnajib also asked what initial steps Dmitry recommended for companies that wanted to start IPv6 deployment but were limited by budget and resources. Dmitry said yes to the first question. To the second, he recommended changing internal procedures. Benedikt Stockebrand said that if operators needed IPv6 in some area, they should address that first. Otherwise, they should first implement it somewhere easy, such as where not much budget or not many employees were required. If a company had a student working for them, they could ask this student to look into implementing IPv6. 3. IPv6 in large Organisations - Lessons learned Wilhelm Boeddinghaus, Route 128 GmbH The presentation is available at: https://ripe91.ripe.net/programme/meeting-plan/sessions/37/UEK3QK/ Wilhelm presented about the challenges in training employees of large organisations on implementing IPv6. He noted the problem began even in universities, where there was a lack of proper networking education. On top of this, he had observed that his customers at enterprises did not want to spend much time and money on implementing IPv6 and so often did not pursue training on this. His training team had therefore shortened their courses so that these customers had time to attend. There was also a lack of interest and preparedness for IPv6 implementation. Many server administrators did not want to learn about the details of BGP and did not have an inventory of specific data they were running on their networks. This was a problem because they needed this inventory as a starting point to see if their infrastructure was capable of running IPv6. However, he found operators sometimes delayed implementing IPv6 by spending years on doing inventory. Wilhelm said operators should instead start as soon as they can, probably through some smaller starting point, not through tackling the whole network at first. Jen Linkova, Google, asked what he thought about long-term infrastructure replacement plans. She noted it was important to think about upgrade plans early on while fixing existing infrastructure to make sure that any new equipment bought was actually capable of running IPv6. Wilhelm said organisations wanted new equipment that could run IPv6 but were not able to test new equipment to make sure of this. He noted many organisations used old equipment for as long as they could. Ondřej Caletka, RIPE NCC, said they had noticed suppliers for their internal systems discontinuing on-premises in favour of IAAA, which might be IPv4-only. So despite trying to do IPv6, they found new products were forcing IPv4, making it hard to switch. He asked if Wilhelm had also noticed this trend and if he knew of any solutions. Wilhelm said he had no solution. The problem was less the push to IPv4 and more that operators were being forced to use the cloud. It was an issue for European federal agencies to have their network management take place in an American cloud that could risk their privacy or be shut down, causing them to lose everything. These operators needed to use a European cloud or use just open source and run everything on-premises. Stefan Wahl, Route 128 % Open 7, said they had seen zero trust models that had caused IPv4 to be re-prioritised. He recommended checking the traffic and making sure it was IPv6 before shutting off IPv4. Mick O'Donovan, HEAnet CLG, asked if Wilhelm had seen enterprises' cybersecurity teams discouraging operators from switching to IPv6 or using public IPv4 and instead encouraging the use of NAT. Wilhelm said he saw this quite often, as uninformed IT teams often thought IPv6 was insecure. Mick said there was fearmongering, especially after a cyberattack, leading to some people not wanting any public addressing. Wilhelm said they would eventually have to deploy anyway. He recommended not working with organisations that refused to use IPv6 and noted there was a RIPE Document that said this as well. Benedikt Stockebrand, Stepladder IT Training+Consulting GmbH, said people often planned changes for when they retired so they could avoid doing them. He encouraged organisations to hang on to any IPv6 enthusiasts working for them who wanted to actually get things done. Saiidnajib Saidislomzoda, CJSC Babilon-Mobile, asked what Wilhelm recommended to overcome delays caused by over-planning and lack of training. Wilhelm said it was necessary to find a middle ground between too much and too little training. He recommended getting a consulting company to help with IPv6. Monika Ermert, elance, asked if he knew of any universities that were doing a good job in educating about IPv6. Wilhelm said he had not heard of any. Universities usually just taught theory, not how to run operating systems in day-to-day work or how to manage networking. It would be good if they taught more networking and protocol theory. Joerg Dorchain, MPI Informatics, said it was different at his institute. 4. DHCPv6 Prefix Delegation for Android Jen Linkova, Google The presentation is available at: https://ripe91.ripe.net/programme/meeting-plan/sessions/37/YXRZB8/ Jen shared that Android could now support DHCPv6. To explain how, she went over some of the differences between IPv4 and IPv6. One advantage of IPv6 was that it usually had multiple addresses: stable, temporary and secured. This affected scalability and the effectiveness of SLAAC with a high number of devices. She explained how to use prefix delegation for hosts and noted that if prefix delegation was enabled, Android could run on only DHCPv6, even if the P-flag was not present. This meant that operators could get the best of both worlds by having the flexibility of SLAAC and a managed network with no scalability issues, at least with trusted hosts. Jan Žorž, ProVision, asked if there were plans to put prefix delegation into SLAAC. Jen said she had seen discussions on doing this, but she could not find a way to configure it. She offered to discuss it with him if he had more information about it. 5. Thanks, Wrap Up and Rate the Talks Raymond thanked attendees and closed the session. For Internal Use Only
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ipv6-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
