- ipv6-wg - mailman.ripe.net

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

25 Jun '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

3 2

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