- ipv6-wg - mailman.ripe.net

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