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
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
