- ipv6-wg - mailman.ripe.net

Multi-Stakeholder Forum on Internet Standards Deployment
by MARTIN Ruediger 27 Nov '25

27 Nov '25

Hi all, The European Commission is setting up a Multi-Stakeholder Forum on Internet Standards Deployment, looking into strengthening the deployment of existing standards and operational best practices in four areas: - IPv6 - modern E-mail communication standards - DNS security - Routing security & hygiene The initiative was presented during its conceptual phase at RIPE 90 in the cooperation working group. The idea is to bring together valuable deployment expertise to capture proven approaches in multi-stakeholder guidelines that support broad and coordinated adoption across sectors. Participation is open to anyone with relevant experience and interest. More information and how to join: https://digital-strategy.ec.europa.eu/en/news/european-commission-seeks-par… Some of you may have seen this elsewhere; sharing it here as well since it may be relevant to this list. Best, Rüdiger ---- Rüdiger MARTIN Internet Governance [cid:image001.jpg@01DC5FB5.FCCF5E00] European Commission DG Communications Networks, Content and Technology (CONNECT) L-51 DCS B-1049 Brussels/Belgium +32 2 298 82 50 Ruediger.MARTIN(a)ec.europa.eu<mailto:Ruediger.MARTIN@ec.europa.eu>

1 0

Draft minutes IPv6 working group sessionat ripe 91
by Raymond Jetten 21 Nov '25

21 Nov '25

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

1 0

CLAT for Windows: Private Preview
by Jen Linkova 19 Nov '25

19 Nov '25

Do you have an IPv6-mostly network? Do you have Windows devices which still consume precious IPv4 addresses? Great news, everyone, the future is already here – it's just not evenly distributed! https://techcommunity.microsoft.com/blog/NetworkingBlog/windows-clat-enters… Pls sign up for the private preview! -- Cheers, Jen Linkova

1 0

Thank you for IPv6 WG @ RIPE91!
by Christian Seitz 25 Oct '25

25 Oct '25

Dear IPv6 Working Group mailing list members, I'd like to say thank you for the IPv6 WG session on Thursday morning. There have been good discussions after the presentations! For future meetings we'll also allow more time for discussion. In the past, we often had to keep the Q&A short because of the packed agenda. Thanks to the presenters Dmitriy Melnik, Wilhelm Boeddinghaus and Jen Linkova and everybody else who submitted a presentation, but has not been selected. Also thanks to Wolfgang Tremmel, our new co-chair, for his support, Raymond Jetten for his continued support until the end of Nicos term and to Nico Schottelius for his time as a co-chair. See you all in Edingburgh, and don't forget to rate the talks ;-) Ray, Wolfgang & Chris

1 0

anyone experienced this trouble with Fortinet (authenticator+firewall) and Windows AD
by jordi.palet＠consulintel.es 20 Oct '25

20 Oct '25

Hi all, Just wondering if this may be a bug or just some misconfiguration and someone in the list experienced this before. I’ve got this question from a dual-stack deployment, I will try to summarise it with the info I’ve got (not my deployment, just trying to help). Network using Windows AD and basically only Windows clients. The Windows clients are dual-stack and are authenticated in the AD. The DNS registers correctly both their IPv4 and IPv6 addresses. The Fortinet authenticator is pulling every few seconds via LDAP to the AD in order to “allow” certain groups of users to get access to Internet thru the firewall. The firewall rules are based on the user IPv4 and IPv6 addresses. It seems that this means that because the user has registered initially with IPv6 (as in dual stack takes precedence over IPv4), is reported by the authentication event from the AD to the Fortinet authenticator only the IPv6 address, so it is only gaining access to IPv6. So how you fix this in the authenticator so it gathers both the IPv4 and IPv6 addresses and consequently open the firewall for both IPv4 and IPv6 of this user? Right now it seems the only way to force the authenticator to recognise both the IPv4 and IPv6 addresses of the user is to reautenticate the user with both addresses. It looks to me strange that the authenticator only looks for the “registration event” with a single IP address and not both of them (IPv4 and IPv6, or even multiple IPv6 addresses - like the privacy one). I tried to help looking for Fortinet documents about this, but didn’t found anything relevant. Anyone has seen this behaviour before and/or has any idea about how to fix it? 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 7

Agenda for the ripe 91 meeting
by Raymond Jetten 15 Oct '25

15 Oct '25

Hello All, We are pleased to announce we have an agenda for the IPv6 Working group next week in Bucharest. https://ripe91.ripe.net/programme/meeting-plan/sessions/37/ We hope to see all of you next week at the meeting ! Christian Seitz & Raymond Jetten For Internal Use Only

1 0

RFC 9096 with dynamic IPv6 and radvd
by Max Emig 09 Oct '25

09 Oct '25

Hi all, what is the best way to implement https://www.rfc-editor.org/rfc/rfc9096.html#section-3.5 i.e. advertising stale prefixes with lifetime 0 with arguably the most popular Router Advertisement daemon? Yes, getting only dynamic IPv6 from consumer ISP is bad, but there are also other, more sensible usecases. This is concerning https://github.com/opnsense/core/issues/9261, which I may get involved in. Feel free to contact me off list to avoid clutter, my takeaway is that while FRITZ!Box and OpenWrt behave nicely, barely anything “more professional” does. Thanks Max

3 2

Co chair selection for the IPv6 WG
by Raymond Jetten 07 Oct '25

07 Oct '25

Dear members of the list. Today the deadline for showing interest for the position of IPv6 Co-Chair has ended. We had 2 candidates, but after introducing them to each other yesterday the other one decided to no longer run for this. So with 1 candidate left, we are honoured to announce that Wolfgang Tremmel will be the new co-chair of the ipv6 Working group. Feel free to show your support for Wolfgang on the list, we are very happy to have him. The official announcement will take place at the IPv6-wg session in Bucharest. Thanks and hope to see you in Bucharest. Christian and Ray For Internal Use Only

5 4

https://test-ipv6.com is announcing retirement
by Geert Jan de Groot 05 Oct '25

05 Oct '25

Hi folks, In past years, I have used https://test-ipv6.com/ as a quick "sanity test" when connecting to a network, using a guest network, or to check network configuration after making changes. I found it very useful for quick tests. Unfortunately, jfesler is announcing sunsetting the project, see https://retire.test-ipv6.com/. In the FAQ, it is mentioned "Q: Will I (jfesler) transfer the domain? A: I’d consider a reputable RIR or NIC organization serving the public interest taking things over." I wonder if a RIR or NIC organisation would consider taking over to run the service. I think it is too useful to just disappear, there are still too many not-quite-IPv6 networks, and personally I hope I don't lose the service. Thoughts, anyone? Geert Jan

3 3

APRICOT 2026: Call for Volunteers (Programme Committee)
by Mark Tinka 31 Aug '25

31 Aug '25

Hello all. The APRICOT 2026 Organising Committee would like to welcome everyone to join us in Jakarta, Indonesia, from 5th - 12th February 2026. The APRICOT 2026 PC (Programme Committee) is responsible for the solicitation and selection of suitable presentations and tutorial content for the APRICOT 2026 conference (https://2026.apricot.net/) We are now seeking VOLUNTEERS from the community to join the APRICOT 2026 PC to assist with the development of the programme for APRICOT 2026. Eligible PC candidates must have attended recent APRICOT events, be active members of their local NOG (Network Operators Group) in the Asia Pacific region, have broad technical knowledge of Internet operations, and have good familiarity with the format of APRICOT. Having constructive opinions and ideas about how the programme content might be improved is of high value too. PC members are expected to work very actively to solicit content, follow-through with speaker updates and review submissions for technical merit. The PC meets by conference call, weekly in frequency during the three months prior to APRICOT. While participation in the weekly calls is not obligatory, active participation in content reviews is required at all times to help the PC reach consensus. PC members who are unable to fully participate in the programme development will be excused from the PC. If you are interested in joining the PC and meet the above eligibility criteria, please send a brief note to "pc-chairs at apricot.net". The note must include affiliation (if any) and a brief description about why you would make a good addition to the PC. The PC Chairs will accept nominations received by 17:00hrs UTC+8 on Sunday 7th September 2025, and will announce the new PC shortly thereafter. Many thanks! Mark Tinka, Achie Atienza & Mark Duffell APRICOT 2026 Programme Committee Chairs

1 0

Call for IPv6 WG presentations at RIPE 91
by Christian Seitz 25 Aug '25

25 Aug '25

Dear IPv6 WG mailing list members, RIPE 91 will be held in Bucharest, Romania from 20-24 October 2025, as well as online. For any form of participation you can register at https://ripe91.ripe.net/attend/attendee-info/register/ Please keep in mind that the early bird rate is only available until 21st of July 2025! The IPv6 Working Group session is scheduled for Thursday 23 October from 9:00 - 10:30 (UTC+2). We are looking for presentations! In the last years only sessions for the Plenary could be registered via the website and the WG presentations needed to be sent via email to the WG chairs. This has changed for the next meeting and we are now using Pretalx for all presentations! Please submit your presentations here: https://ripe91.ripe.net/present/call-for-presentations/ You will need a RIPE NCC Access account and enable two-factor authentication in order to access the submission system. If you don't have a RIPE NCC Access account yet, please create it here: https://access.ripe.net/registration If you like to discuss your presentation with us first, please email ipv6-wg-chair(a)ripe.net. The deadlines mentioned on the CfP page above are for the Plenary. For the WG session we also accept submissions after the deadlines, but for better planning we prefer to have your submission as soon as possible. On 20th of September we will start to decide about the agenda and see, if we still have open slots. Once we have decided on the agenda, we'll contact the presenters. We expect to have a draft of the presentations about two weeks before the meeting and the final slides at least two days before our session. On behalf of the IPv6 WG co-chairs, Ray and Chris

3 3

Call for IPv6 WG Co-Chair candidates
by Christian Seitz 25 Aug '25

25 Aug '25

Dear IPv6 WG list, we would like to inform you that Nico Schottelius resigned from his position as IPv6 WG Co-Chair. The regular end of his term would have been RIPE94. The IPv6 WG thanks Nico for his term as Co-Chair. Ray's term ends after the next RIPE91 meeting. I am pleased that Ray has agreed to continue and our current plan is for Ray to serve Nico's term until RIPE94. We are now looking for a new Co-Chair for a regular three-year term on RIPE91. A Co-Chair may stand for re-selection at the end of his term or may resign voluntary for any reason at any time. What is the IPv6 Working Group doing? The working group activities may be anything useful in helping people to deploy IPv6, and to manage IPv4/IPv6 co-existence. These activities include: * Outreach * Education * Sharing deployment experiences * Discussing and fixing operational issues The Co-Chairs also prepare the program for the IPv6 WG session at the RIPE meetings and also moderate the session and prepare the speakers. It is important for us that a new Co-Chair candidate will be able to attend the RIPE meetings in person. The working group will cooperate with operators and others, both inside and outside the networking industry, to share resources and combine efforts. The tasks and expectations of a WG Co-Chair are described here: https://www.ripe.net/publications/docs/ripe-692 A WG Co-Chair must comply with the Code of Conduct: https://www.ripe.net/publications/docs/ripe-766 If you feel you are interested in this or have any questions on this, you can drop the current Co-Chairs a note at ipv6-wg-chair(a)ripe.net. We kindly request you to respond no later than Friday 03. October 2025 midday CET (Amsterdam), when the call for candidates closes. After this we will announce the candidates on the list, and you can express your support. The official selection will take place at the RIPE 91 Meeting in Bucharest during the IPv6 Working Group session. On behalf of the IPv6 WG Co-Chairs, Ray and Chris

4 3

Minutes of the IPv6-wg at RIPE 90
by Raymond Jetten 19 Jun '25

19 Jun '25

Dear members, Here are the draft minutes from the IPv6 Working Group from RIPE 90 If you have any comments or concerns, please let us know as soon as possible. Thank you! IPv6 Working Group Draft Minutes - RIPE 90 Date: Thursday, 15 May 09:00 - 10:30 (UTC+1) Chairs: Christian Seitz, Nico Schottelius, Raymond Jetten Scribe: Virgile Uytterhaegen Status: Draft View the recordings<https://ripe90.ripe.net/programme/meeting-plan/ipv6-wg/> View the stenography transcript<https://ripe90.ripe.net/archives/steno/37/> View the chat logs<https://ripe90.ripe.net/archives/chat/37/> 1. Welcome The presentation is available at https://ripe90.ripe.net/archives/video/1635 Co-chair Raymond Jetten opened the session with a reminder of the Working Group etiquette and Code of Conduct, minutes of the Working Group sessions at RIPE89 were approved with no comment. 2. Amplification through IPv6 routing loops: A call to fix router configurations Maynard Koch, TU Dresden The presentation is available at https://ripe90.ripe.net/archives/video/1637 Maynard presented his research on how a single ICMP echo request to an IPv6 address could trigger a routing loop and generate more than 250,000 replies. With his team, they used public Internet measurements to identify IPv6 routing loops and conducted an email campaign to notify network administrators that they had a misconfiguration in their routers. Jen Linkova, Google, suspected that broken CPE (Customer Premises Equipment) were the cause of the issue because they didn't install null routes for delegated prefixes. She asked if Maynard looked into interface IDs of responding routers to see if there was a pattern. Maynard responded they didn't and that they will take this into consideration for future work. Brian Candler, NSRC, asked for the exact reasons why the packet duplication happened and if it was applicable only to ICMP echo requests. Maynard answered that the cause of the duplication was most likely a hardware issue and they confirmed that with Juniper. He said this could also affect UDP and TCP packets. Alexander Zubkov, Qrator Labs, asked if they tried to identify unique loops because multiple loops could be caused by a single misconfiguration. Maynard said that they found that 60,000 IP routes were affected. Ondřej Caletka, RIPE NCC, pointed out that TTL was part of IPv4 terminology and that Hop Limit Exceeded was the appropriate term for IPv6. 3. IPv6 Support for Multiple Routers, Multiple Interfaces, and Multiple Prefixes Fernando Gont, SI6 Networks, IETF The presentation is available at https://ripe90.ripe.net/archives/video/1642 Fernando talked about the difficulty to run multi-IPv6 scenarios in practice and presented two examples of multi-IPv6 deployments. David Lamparter, NetDEF, Inc., asked how much complexity was needed to support those deployments. He made a point whether it was relevant to support these scenarios for small networks that only have a couple of routers. He encouraged network operators to take part in the IETF discussions on this topic. Jan Žorž, 6Connect, asked how the issue could be solved if network operators update their prefixes every 24 hours. Warren Kumari, speaking for himself, asked if this could be solved using virtual sub-interfaces. Fernando said that from his perspective he didn't see it working in practice. Jen Linkova, Google, said that having two routers meant having two implicit Provisioning Domains and that could be an issue if one of the routers sends RDNSS separately. She asked Fernando which operating system he was using because she was having problems herself with using two different ISPs for an IPv6 prefix. Fernando said he checked all of them and that the information ends up getting mixed and that one of the ISPs would get forgotten. 4. Challenges of Running IPv6-Only Internal Services Ondřej Caletka, RIPE NCC The presentation is available at https://ripe90.ripe.net/archives/video/1639 Ondřej talked about the history of running internal services at the RIPE NCC and the complexity of moving to IPv6 only. He mentioned a specific issue with the stub resolver on macOS for IPv6 only networks. Jen Linkova, Google, asked about using the VPN to push the DNS configuration to the clients to solve the issue. Ondřej said that this was too complicated and should be handled by the internal resolver for internal domains. Jen suggested other solutions using the VPN resolver and Ondřej said he would consider it. Kostas Zorbadelos, NTT DATA, asked if they had tried a different VPN software because this could be causing the issue if the same happened on Windows and Linux. Ondřej said it was most likely that the RIPE NCC's current VPN tool was causing an issue with macOS but it was chosen ten years ago and was one of the only ones with IPv6 support. He said there was a fix implemented by some VPN providers to make scutil work with AAAA records. Because the session was running late, some questions on the chat could not be answered. 5. IPv6-mostly Experiences at Industry Events Éric Vyncke, CISCO and Warren Kumari, Google The presentation is available at https://ripe90.ripe.net/archives/video/1643 Éric and Warren presented their experience of running IPv6-mostly networks at two major events; CISCO Live in Amsterdam and the IETF in Bangkok. Their conclusion was mostly positive, highlighting the efforts made by their networking teams and the lessons they learned along the way. David Lamparter, NetDEF, Inc., said he deployed IPv6 at a hacker's event and to check beforehand that routers implement RFC 9047 because usage of IPv4 addresses dropped to 25% and 75% of devices did not request IPv4 anymore. Jen Linkova, Google, thanked the presenters for their amazing story of fixing SSH on MacOS. Brian Candler, NSRC, asked if DNS64 was still needed for IPv6-mostly deployments because it caused issues with VPN clients. Jen said that it depended on the operating system used. 6. Thanks, Wrap Up and Rate the Talks Raymond Jetten thanked participants and concluded the session. For Internal Use Only

1 0

question about experience in IPv6-only/mostly WIFI with android and iOS
by Thomas Schäfer 31 May '25

31 May '25

Dear IPv6 working group, during the ripe90 meeting I made (and collected) different experiences with WLAN-call (a built in feature for "native" phoning via WIFI instead of via 4G/ 5G). My conclusion is, it strongly depends. (even it does not work reliable in IPv4-only networks). Nevertheless, I don't expect wonders, when using IMS/SIP via ipsec via 464xlat. As long the providers only provide A-Records here: epdg.epc.mnc0XX.mcc262.pub.3gppnetwork.org (for Germany XX 01,02,03/07,23) I think it won't get better. Does anybody know if 3gpp has also IPv6/IPv6 defined ipsec connections for it? (instead of IPv6(payload) via IPv4(transport)) After the meeting another built in function came in to my mind: printing Do people print in android and iOS? Does it work out of the box - "zeorconf" via mDNS/airprint in IPv6-only/mostly? A test in my home environment (cups/avahi) showed: It can work, but only with the alternative print service by mopria. The default/standard print service in android did not work at all. Do you have any experiences with that? Regards, Thomas

2 2

IPv6 WG agenda for RIPE90
by Christian Seitz 01 May '25

01 May '25

Dear IPv6 working group, we received some great submissions for our IPv6 WG session in Lisbon, but unfortunately could not accept all of them. Many thanks to everybody who submitted a presentation, even if we were unable to accept it due to the full agenda! The session will take place on Thursday 15 May 2025 from 9:00 - 10:30 UTC+1. The agenda will also be published in the RIPE90 meeting plan [1] soon. This is our current agenda: 1. Welcome [3 min] Opening and Welcome Approval of RIPE 89 Minutes Microphone Etiquette 2. Amplification through IPv6 routing loops: A call to fix router configurations [15+5 min] Maynard Koch 3. IPv6 Support for Multiple Routers, Multiple Interfaces, and Multiple Prefixes [20+5 min] Fernando Gont 4. Challenges of Running IPv6-Only Internal Services [15+5 min] Ondřej Caletka 5. IPv6-mostly experiences at industry events [15+5 min] Éric Vyncke 6. Thanks, Wrap Up and Rate the Talks [2 min] If there are any changes to this agenda, we will send an update and also update the meeting plan on the website [1]. [1] https://ripe90.ripe.net/programme/meeting-plan/ On behalf of the IPv6 WG co-chairs, Nico, Ray and Chris

1 0

IPv6 Multihoming with Load Balancing
by Jonas Lochmann 10 Mar '25

10 Mar '25

My goal is to use multiple uplinks, but not only for redundancy. Most of the time, all (in my case 2) uplinks are available and then the question is how to make use of both of them. With IPv4, NAT is common and thus the solution is quite simple. In my case, I am using the mwan3 package from OpenWrt. It uses iptables rules to add firewall marks to connections. If multiple uplinks are available, then the mark/uplink is chosen randomly and assigned to this (e.g. TCP) connection. This firewalls marks are used during a policy based routing. With a masquerade/source NAT, the right source address for the used route is picked and everything just works. In case of IPv6, everything is different. NAT is uncommon. One solution is to enable NAT and then everything works as with IPv4. Alternatively, RFC 8678 describes that clients can be informed about multiple uplinks. The limitation: I do not see any option for load balancing. RFC 8678 references other solutions. Shim6 seems to be not widely implemented. The Multipath Transports look like a solution for the future with Mulitpath TCP. The last solution is NPTv6. RFC 8678 does not like the solution. It is no NAT, but it still rewrites the addresses. The disadvantage: Stateless address rewriting seems only usable if there is only one prefix known to the network. If this is the global prefix of one uplink, then all connections are interrupted if the prefix of this uplink is changed. If this is the local prefix, then the clients do not know their public addresses. I tried to use a stateful source address rewriting instead. With nftables, this is easy to implement and it works if the prefix length of the uplink is longer (smaller subnet) than the internal network: Just keep the prefix and replace the bits after it with the original source address. With this, I can use local addresses in the local network and additionally provide the public address/es of one or more uplinks. I am using this in production at one location since multiple years and thus know that this works. I am interested in other approaches, experiences and feedback for this method.

13 25

Multi-ipv6 support (multi-router, multi-interface, multi-prefix) IETF draft
by Fernando Gont 04 Mar '25

04 Mar '25

Hi, I have posted a revision of draft-gont-v6ops-multi-ipv6. This document contains the problem statement regarding the support of multiple routers, multiple interfaces, and multiple prefixes by IPv6 hosts. This revision polishes the text quite a bit, and incorporates two "failure" scenarios that should be supported, such that if you have a working set {source address, next-hop, RDNSS), you can survive network outages. URL: https://www.ietf.org/archive/id/draft-gont-v6ops-multi-ipv6-02.txt HTMLized: https://datatracker.ietf.org/doc/html/draft-gont-v6ops-multi-ipv6 Your comments will be very appreciated! Thanks, Fernando -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-v6ops-multi-ipv6-02.txt Date: Mon, 03 Mar 2025 15:57:16 -0800 From: internet-drafts(a)ietf.org To: Fernando Gont <fgont(a)si6networks.com> A new version of Internet-Draft draft-gont-v6ops-multi-ipv6-02.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-v6ops-multi-ipv6 Revision: 02 Title: Problem Statement about IPv6 Support for Multiple Routers, Multiple Interfaces, and Multiple Prefixes Date: 2025-03-03 Group: Individual Submission Pages: 15 URL: https://www.ietf.org/archive/id/draft-gont-v6ops-multi-ipv6-02.txt Status: https://datatracker.ietf.org/doc/draft-gont-v6ops-multi-ipv6/ HTMLized: https://datatracker.ietf.org/doc/html/draft-gont-v6ops-multi-ipv6 Diff: https://author-tools.ietf.org/iddiff?url2=draft-gont-v6ops-multi-ipv6-02 Abstract: This document discusses current limitations in IPv6 Stateless Address Auto-configuration (SLAAC) that prevent support for common multi- router, multi-interface, and multi-prefix scenarios. It provides discussion on the challenges that these scenarios represent, and why a solution in this space is warranted. Finally, it specifies a number of common scenarios that any solution in this space should be able to address. The IETF Secretariat

1 0

Call for IPv6 WG presentations at RIPE 90
by Christian Seitz 21 Feb '25

21 Feb '25

Dear IPv6 WG mailing list members, RIPE 90 will be held in Lissabon, Portugal from 12-16 May 2025, as well as online. For any participation form you can register at https://ripe90.ripe.net/attend/register/. The IPv6 Working Group session is scheduled for Thursday 15 May from 9:00 - 10:30 (UTC+2). We are looking for presentations! Please email ipv6-wg-chair (at) ripe.net if you'd like to present. Please also state if you intend to be onsite or remote, the duration of your presentation, and a short description of it. On 14th of April we will start to decide about the agenda and see, if we still have open slots. Once we have decided on the agenda, we'll contact the presenters closer to the meeting. We expect to have a draft of the presentation about two weeks before the meeting and the final slides at least two days before our session. On behalf of the IPv6 WG co-chairs, Nico, Ray and Chris

1 0

Revision of IETF I-D on IPv6 multi-router, multi-prefix, and... hopefully not NATs! :-)
by Fernando Gont 03 Feb '25

03 Feb '25

Folks, We have posted this minor rev of our I-D on the problem statement about IPv6 support for multiple-prefixes and multiple-routers). The revised I-D is here: https://datatracker.ietf.org/doc/html/draft-gont-v6ops-multi-ipv6 We plan to post a revision in two weeks or so (mostly addressing the feedback we got for the -00 version). If you have any comments on the I-D, or thoughts on the topic, please do let us know! -- I'll make my best for your feedback to be addressed in the next rev. Thanks! Regards, Fernando -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-v6ops-multi-ipv6-01.txt Date: Sun, 02 Feb 2025 18:18:48 -0800 From: internet-drafts(a)ietf.org To: Fernando Gont <fgont(a)si6networks.com> A new version of Internet-Draft draft-gont-v6ops-multi-ipv6-01.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-v6ops-multi-ipv6 Revision: 01 Title: Problem Statement about IPv6 Support for Multiple Routers and Multiple Prefixes Date: 2025-02-02 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/archive/id/draft-gont-v6ops-multi-ipv6-01.txt Status: https://datatracker.ietf.org/doc/draft-gont-v6ops-multi-ipv6/ HTMLized: https://datatracker.ietf.org/doc/html/draft-gont-v6ops-multi-ipv6 Diff: https://author-tools.ietf.org/iddiff?url2=draft-gont-v6ops-multi-ipv6-01 Abstract: This document discusses current limitations in IPv6 Stateless Address Auto-cofiguration (SLAAC) that prevent support for common multi- router and multi-interface scenarios. It provides discussion on the challenges that these scenarios represent, and why a solution in this space is warranted. Finally, it specifies a number of common scenarios that any solution in this space should be able to address. The IETF Secretariat

1 0

using 2002 prefix for mail at IONOS/kundenserver.de?
by jordi.palet＠consulintel.es 21 Jan '25

21 Jan '25

Hi all, I’m wondering if I’m understanding this correctly and if so, if it is a good practice. In email mesases received from IONOS, I see in the header: X-Received: by 2002:ac8:5ac5:0:b0:46d:fd08:7c9f with SMTP id d75a77b69052e-46e12a462a7mr251941861cf.22.1737462364476; Tue, 21 Jan 2025 04:26:04 -0800 (PST) Another example: X-Received: by 2002:a05:622a:38b:b0:46c:7646:4a1e with SMTP id d75a77b69052e-46e12a62966mr243715391cf.13.1737416130721; Mon, 20 Jan 2025 15:35:30 -0800 (PST) It looks to me like they are using 2002 as the IPv6 address of the email for the client hosted mail/domains? 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

APRICOT 2025: Call for Papers
by Mark Tinka 07 Jan '25

07 Jan '25

Hello all. The APRICOT 2025 Programme Committee is now seeking contributions for Presentations and Tutorials for the APRICOT 2025 Conference, which will be held in Petaling Jaya, Malaysia, 19th - 27th, February 2025. Details about the Call for Papers, and how you can submit a proposal for a conference, peering and tutorial talk, and the submission deadlines, can be found at the link below: https://2025.apricot.net/programme/callforpresentations We look forward to receiving your papers, and seeing you in Malaysia. Many thanks! Mark Tinka, Achie Atienza & Mark Duffell APRICOT 2025 Programme Committee Chairs

1 2

Minutes from RIPE 89
by Christian Seitz 29 Nov '24

29 Nov '24

Dear IPv6 WG list members, you can find the draft minutes from the IPv6 WG session held during RIPE 89 in Prague on the website [1]. Thanks to the RIPE NCC for taking them! If you have any comments or questions, please let us know. [1] https://www.ripe.net/community/wg/active-wg/ipv6/minutes/ipv6-working-group… --------------------CUT-------------------- IPv6 Working Group Minutes - RIPE 89 ==================================== Date: Thursday, 31 October 09:00 - 10:30 (UTC+1) Chairs: Christian Seitz, Nico Schottelius, Raymond Jetten Scribe: Emile Aben Status: Draft View the recordings (https://ripe89.ripe.net/programme/meeting-plan/ipv6-wg/) View the stenography transcript (https://ripe89.ripe.net/archives/steno/40/) View the chat logs (https://ripe89.ripe.net/archives/chat/40) 1. Welcome ---------- The presentation is available at: https://ripe89.ripe.net/archives/video/1491 Co-chair Christian Seitz opened the session. 2. Why Is This IPv6 Transition Taking So long? ---------------------------------------------- Geoff Huston, APNIC The presentation is available at: https://ripe89.ripe.net/archives/video/1493 Wai Sing Samson Chooi (Messrs. Chang Chooi & Co.) asked if the RIPE NCC had resources to support capacity building for new members. Raymond Jetten (co-chair) responded that the RIPE NCC had quite a few training available. Kurt Kayser (Kurt Kayser Konsultation) objected to comparing IPv6 to steam trains and asked Geoff to change the analogy. The room applauded Kurts’ suggestion. Geoff acknowledged the suggestion. Steve Wallace (Internet2) brought up the 2,600 ASNs that make up the global Research and Education Networks as a counter example. Geoff answered that research and commercial networks have diverged, and that scaling properties of address-based architectures was really difficult and expensive. Jen Linkova (Google) completely disagreed with Geoff that NAT is free as she was dealing with users that were unhappy about it. She agreed that the problem with the transition was human nature, as many only acted if it was really needed. Geoff replied that IPv4 could only be turned off when it was no longer in use and that, from an economic point of view, there was no momentum for the transition. 3. K8s IPv6 and Routing ----------------------- Nico Schottelius, ungleich The presentation is available at: https://ripe89.ripe.net/archives/video/1497 Jan Zorz (6connect) asked if you could do VPP DPDK in these containers. Nico replied that it was possible. Dmytro Shypovalo (Vegvisir Systems) asked if Nico explored SRv6 with Kubernetes. Nico said that he did not. Advent of IPv6 Jens Link The presentation is available at: https://ripe89.ripe.net/archives/video/1498 Ondřej Caletka (RIPE NCC) liked the idea of an IPv6 advent calendar and said the RIPE NCC has content to contribute. He offered to help. Jens then asked the room if it was a good idea or not. The feeling in the room was that it was a good idea. Jens asked who would be willing to volunteer and got only a few hands up. Jen Linkova (Google) offered the idea of giving people pcaps to take a look at what’s wrong with them. Jens thought that was a good idea. Raymond concluded that Jens’ idea looked like a good idea. 4. What We Have Achieved So Far ------------------------------- Benedikt Stockebrand (stepladder IT) The presentation is available at: https://ripe89.ripe.net/archives/video/1500 Jen Linkova (Google) said that there was no point in telling people what to do, so she disagreed with the advice and pointed out that we needed technical solutions to stop bad things happening. She asked if Benedikt had any figures on the increasing number of routes that made him so concerned about the routing table. Benedikt replied that he had anecdotal evidence. Jen said that she had seen large deaggregation events, but that those were mistakes and could be mitigated by setting max prefix limit. She suggested Benedikt to go into more technical details on how to prevent bad things from happening. Benedikts' advice was to remain alert and that it was difficult to give advice beyond monitoring and being prepared. Yannis Nikolopoulos (CellMobile) asked to what extent we have failed with transition technologies. Benedikt replied that they prolonged the pain because they are difficult to use and cost a lot of money. Gert Doring (Spacenet) replied that transition technologies were in fact extremely well made. Gert then gave the advice to filter customers for what they intend to announce. Benedikt responded that he suspected a serious impact due to new entrants that are not ISPs in the next couple of years. Regarding routing and disaggregation, Gert said that people should filter their clients. He added that this was something that all transit networks should be doing, and that most people in the room were already doing, so this was not the right forum. Benedikt said the key point was to have a rush of non-ISP players, and he suspected a serious impact in that regard. 5. Wrap Up ---------- This part of the session is available at: https://ripe89.ripe.net/archives/video/1501/ Ondřej Caletka (RIPE NCC) had an AOB. He asked for NetworkManager to support IPv6-only networks. He specifically asked paying customers of the product to make this request. Raymond then closed the session. --------------------CUT-------------------- Thanks and kind regards Chris -- Individual Network Berlin e.V. : support(a)in-berlin.de : vorstand(a)in-berlin.de Tel +49-30-45494343 ::: Fax +49-30-45494344 ::: Web https://www.in-berlin.de/ IN-Berlin e.V. : Christian Seitz (1. Vors.) : Lehrter Str. 53 :: 10557 Berlin Amtsgericht Charlottenburg 95 - VR 15669 Nz ::::::: USt.Ident-Nr. DE188894648

2 2

Technical Trainer and Development Officer role at the RIPE NCC
by Lilis Rodriguez Amador 29 Nov '24

29 Nov '24

Dear all, The RIPE NCC has a vacancy for a Technical Trainer and Development Officer with a particular focus on IPv6. The Learning and Development department is looking for a new colleague to develop and create training materials and exams. And, of course, deliver technical training courses, webinars and presentations. This is a role for people who are knowledgeable about IPv6 and enjoy sharing technical knowledge with a wide audience. Our courses are taken by people throughout Europe, the Middle East and parts of Central Asia, so we are looking for someone curious, enthusiastic, empathetic, and excited to work with people from diverse cultures. If this sounds like an interesting opportunity to you, please read our Technical Trainer vacancy and apply: https://ripencc.recruitee.com/o/technical-trainer-development-officer-1 Important: the ideal candidate should be living in the Netherlands or willing to relocate. *Warm regards,* [image: This is Lilis Rodríguez's card. Their email is lrodriguez(a)ripe.net. Their phone number is +31 6 55003375.] <https://hihello.me/p/fc1bd8d9-38fc-4e27-83b6-cc2ddb2b8077?referer=email_sig…> [image: Mailsuite] Sent with Mailsuite · Unsubscribe <https://mailsuite.com/en/privacy/opt-out/unsubscribe/f60fc3b5a688daf542d66e…> 29/11/24, 10:11:17

1 0

Problem Statement about IPv6 Support for Multiple Routers and Multiple Interfaces (Fwd: New Version Notification for draft-gont-v6ops-multi-ipv6-00.txt)
by Fernando Gont 28 Nov '24

28 Nov '24

Hi, We've decided to bite the bullet, and have posted this IETF I-D: "Problem Statement about IPv6 Support for Multiple Routers and Multiple Interfaces" HTMLized: https://datatracker.ietf.org/doc/html/draft-gont-v6ops-multi-ipv6 TXT: https://www.ietf.org/archive/id/draft-gont-v6ops-multi-ipv6-00.txt Status: https://datatracker.ietf.org/doc/draft-gont-v6ops-multi-ipv6/ Feedback/discussion will be very appreciated. Thanks! Regards, Fernando -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-v6ops-multi-ipv6-00.txt Date: Wed, 27 Nov 2024 21:00:07 -0800 From: internet-drafts(a)ietf.org To: Fernando Gont <fgont(a)si6networks.com>, Guillermo Gont <ggont(a)si6networks.com> A new version of Internet-Draft draft-gont-v6ops-multi-ipv6-00.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-v6ops-multi-ipv6 Revision: 00 Title: Problem Statement about IPv6 Support for Multiple Routers and Multiple Interfaces Date: 2024-11-27 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/archive/id/draft-gont-v6ops-multi-ipv6-00.txt Status: https://datatracker.ietf.org/doc/draft-gont-v6ops-multi-ipv6/ HTMLized: https://datatracker.ietf.org/doc/html/draft-gont-v6ops-multi-ipv6 Abstract: This document discusses current limitations in IPv6 Stateless Address Auto-cofiguration (SLAAC) that prevent support for common multi- router and multi-interface scenarios. It provides discussion on the challenges that these scenarios represent, and why a solution in this space is warranted. Finally, it specifies a number of common scenarios that any solution in this space should be able to address. The IETF Secretariat

1 0

Can someone kick dana yazdani off the list please?
by Leslie 27 Nov '24

27 Nov '24

Can someone kick the spammer off the list please? Thanks!

2 1