- ipv6-wg - mailman.ripe.net

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