- ipv6-wg - mailman.ripe.net

Reminder: Tomorrow's RIPE NCC Open House Event on Community Projects Fund Updates - 21 September, 10:00 - 11:30 UTC
by Alastair Strachan 20 Sep '23

20 Sep '23

Dear colleagues, I hope all is well with you. Just a quick note to remind you about the RIPE NCC Open House event happening tomorrow, Thursday, 21 September 2023, from 10:00 to 11:30 UTC. It's an excellent chance to hear firsthand updates from the recipients of last year’s Community Projects Fund and to engage in meaningful dialogue with project leaders. The agenda includes presentations where each project will provide an overview of their journey and accomplishments so far. Following the presentations, there will be a Q&A segment for any questions you may have. The projects and speakers lined up for tomorrow are: 1. Foundation for Research and Technology - Hellas (FORTH) Project: ARTEMIS Lite Speaker: George Nomikos 2. Grenoble Alps University Project: fpdns2: DNS Fingerprinting Tool Speaker: Yevheniya Nosyk 3. University of Aberdeen Project: Can We Extend IPv6? - A Measurement Project Speaker: Ana Custura For more details and to register for the event, please visit the following link: https://www.ripe.net/participate/meetings/open-house/ripe-ncc-open-house-se… RIPE NCC Open House Series: Community Projects Fund Recipient Updates 2022 ripe.net We hope to see you there! Kind Regards, Alastair Strachan RIPE NCC

1 0

IPv6 multi-homing for site resilience
by Paolo Volpato 15 Sep '23

15 Sep '23

Dear WG, To document the currently available IPv6-based solutions to support multi-homing connectivity (e.g. a typical requirement of an enterprise site) we have developed the draft "IPv6 Site Connection to Many Carriers" (https://datatracker.ietf.org/doc/draft-fbnvv-v6ops-site-multihoming/). The draft, co-authored by five people, is active in the IETF v6ops WG. The target we’d like to achieve is to provide a list of the possible ways to support multi-homing through IPv6, discussing the pros and the cons of each method. You will notice, we have included in the current list the common mechanisms (e.g. PI addressing or PA multi-prefix assignment) but also NPTv6 and even NAT66, despite the fact that are not considered positively by the majority of the IPv6 community. The reason for sharing is twofold. On the one hand, we’d like to get the feedback of the community on the technical content, e.g. whether anything is missing or needs more discussion. On the other, we have prepared a short survey to collect data from the field and get a picture of the solutions that are more widely deployed. The survey is anonymous and can be accessed here: https://docs.google.com/forms/d/e/1FAIpQLSdvj4VtixaoXpMpfXhUJawXdQ60MzBKKp6…. If possible, we’ll discuss the draft content and the relevant survey at the next RIPE meeting. Thank you for your cooperation. Paolo

1 0

Status IPv6 Policy Draft
by Tobias Fiebig 14 Sep '23

14 Sep '23

Heho, i am currently scrolling over my inbox, and was wondering what the status of the v6 policy draft is (with 87 coming up). Is anyone already working on a draft to discuss? Otherwise, I could take a shot to have something ready closer to 87 which picks up the major points from prior discussions. With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tobias(a)fiebig.nl

1 1

Clear Guidance for Enterprises
by Wilhelm Boeddinghaus 01 Aug '23

01 Aug '23

Hi, at the end of my talk during the RIPE86 IPv6 working group I promised to start work on a paper with clear guidance for enterprises to migrate their networks to IPv6. We have often wondere why enterprises do not migrate to IPv6. One possible answer is: They have no time and they lack knowledge. Many IT departments don't have any spare time for reading RFCs. From my understanding these IT departments don't need papers explaining the many possibilites to choose from. They need very clear guidance and examples. I am looking for 3 to 4 people who would like to start working on this with me. Peter Hessler contacted me during the meeting and he offered his help, time and expertise for this project. Thank you, Peter. Best, Wilhelm

18 28

Re: [ipv6-wg] contents of ipv6-wg Digest, Vol 135, Issue 10
by Clodagh Durkan 26 Jun '23

26 Jun '23

Hi Wilhelm, all, I am also really interested in this topic, really suspect it’s not broken for the most enterprises so why invest into what’s a whole new re architecture, skills in-house may also not exist. expensive in people and technology and high risk migration. Gsma announced this year global IOT devices surpassed SIMs this year, both now at 2bn + so change is already coming from the networks. I would really like to contribute however I can, Clodagh.durkan(a)ucdconnect.ie or gmail above Best regards, Clodagh On Thu 15 Jun 2023 at 11:00, <ipv6-wg-request(a)ripe.net> wrote: > Send ipv6-wg mailing list submissions to > ipv6-wg(a)ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.ripe.net/mailman/listinfo/ipv6-wg > or, via email, send a message with subject or body 'help' to > ipv6-wg-request(a)ripe.net > > You can reach the person managing the list at > ipv6-wg-owner(a)ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ipv6-wg digest..." > > > Today's Topics: > > 1. Re: Clear Guidance for Enterprises (Paolo Volpato) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 14 Jun 2023 16:08:22 +0000 > From: Paolo Volpato <paolo.volpato(a)huawei.com> > To: Wilhelm Boeddinghaus <wilhelm(a)boeddinghaus.de> > Cc: "ipv6-wg(a)ripe.net" <ipv6-wg(a)ripe.net> > Subject: Re: [ipv6-wg] Clear Guidance for Enterprises > Message-ID: <2164ac90f1b34e908d39fe008217be7c(a)huawei.com> > Content-Type: text/plain; charset="utf-8" > > Hi Wilhelm, All, > > I have noticed that some people would be happy to cooperate to your idea > of a paper for IPv6 in enterprises (me included :-) > Wonder if you have thought of any rough plan to start and organize the > work. > > Many thanks > Paolo > > -----Original Message----- > From: Wilhelm Boeddinghaus <wilhelm(a)boeddinghaus.de> > Sent: Thursday, June 1, 2023 4:20 PM > To: Paolo Volpato <paolo.volpato(a)huawei.com> > Cc: ipv6-wg(a)ripe.net > Subject: Re: [ipv6-wg] Clear Guidance for Enterprises > > Hi Paolo, > > thanks for your help with this project. > > Lack of budget is of course a problem. But if the IT departments could at > least quantify the budget, this would help. If they have no idea how to > start the project, a budget eastimation is not possible. > > Best, > > Wilhelm > > Am 31.05.2023 um 08:42 schrieb Paolo Volpato via ipv6-wg: > > Hi Wilhelm, > > > > In addition, I would add that they also lack the budget to consider > deploying IPv6, meaning that enterprises don't consider IPv6 as a priority. > > At least, this is what we found during the editing of RFC 9386 on IPv6 > deployment status. > > > > I would be happy to contribute to this effort. > > > > Best regards > > Paolo > > > > -----Original Message----- > > From: ipv6-wg <ipv6-wg-bounces(a)ripe.net> On Behalf Of Wilhelm > > Boeddinghaus > > Sent: Tuesday, May 30, 2023 6:06 PM > > To: ipv6-wg(a)ripe.net > > Subject: [ipv6-wg] Clear Guidance for Enterprises > > > > Hi, > > > > at the end of my talk during the RIPE86 IPv6 working group I promised to > start work on a paper with clear guidance for enterprises to migrate their > networks to IPv6. > > > > We have often wondere why enterprises do not migrate to IPv6. One > possible answer is: They have no time and they lack knowledge. Many IT > departments don't have any spare time for reading RFCs. > > > > From my understanding these IT departments don't need papers > explaining the many possibilites to choose from. They need very clear > guidance and examples. > > > > I am looking for 3 to 4 people who would like to start working on this > with me. > > > > Peter Hessler contacted me during the meeting and he offered his help, > time and expertise for this project. Thank you, Peter. > > > > Best, > > > > Wilhelm > > > > > > > ------------------------------ > > Subject: Digest Footer > > -- > > To unsubscribe from this mailing list, get a password reminder, or change > your subscription options, please visit: > https://lists.ripe.net/mailman/listinfo/ipv6-wg > > > ------------------------------ > > End of ipv6-wg Digest, Vol 135, Issue 10 > **************************************** >

2 2

Not standing as working group chair for another term
by Benedikt Stockebrand 26 Jun '23

26 Jun '23

Hi folks, as I've already said during the working group session in Rotterdam my term as WG chair ends at the next RIPE meeting. Since I find it increasingly difficult to make the WG chair role agree with my daily work profile (too much firefighting, too little of a routine daily schedule), Jen and Ray had to cover for me more often than I am happy with---thanks, and apology, to both of them. As a consequence however it doesn't make any sense if I stood for another term. We'll start the process of finding a successor for me before RIPE 87. If you are interested in taking over the role, and are willing to keep a pretty much daily eye on the mailing list and such, you may already want to think about volunteering for the job. And one more thing: That doesn't mean that I have lost interest in the WG, or in IPv6 as such---in fact, in my opinion we still have some serious work to do eliminating the hidden dependencies on Vintage IP before they bite us in the backside. More about that at RIPE 87 in Rome... Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/

1 0

IPv6 WG minutes from ripe 86
by Raymond Jetten 13 Jun '23

13 Jun '23

Here are the minutes from the RIPE 86 IPv6 wg session, please let us know if you want anything edited, or they will be published in a week on the website. Date: 24 May 2023, 11:00 - 12:30 (UTC+2) Chairs: Benedikt Stockebrand, Jen Linkova, Raymond Jetten Scribe: Tayfun Ozaltin Status: 1. Welcome Jen Linkova, IPv6 WG Co-chair The presentation is available at: https://ripe86.ripe.net/wp-content/uploads/presentations/8-RIPE-86-IPv6-WG.… Jen Linkova welcomed everyone and introduced the co-chairs. The RIPE 85 minutes were approved. 1. Advanced IPv6 Course Input Request Tayfun Ozaltin, RIPE NCC The presentation is available at: https://ripe86.ripe.net/wp-content/uploads/presentations/105-RIPE-86-Slide-… Tayfun Ozaltin, RIPE NCC, asked for input on the advanced IPv6 e-learning course that was being developed. There were no questions. 1. Deploying IPv6 and/or CGNAT Rinse Kloek, Delta Fiber / Kindes The presentation is available at: https://ripe86.ripe.net/wp-content/uploads/presentations/67-RPE86-IPv6-depl… Rinse explained how their company made a transition from IPv4-only to an IPv6 supporting network. He mentioned the challenges they had during the implementation. Yannis Nikolopulos, Cellmobile, asked who the vendor was and what the real story was behind the denial. Rinse answered that Nokia was the vendor and that they did not support MAP-E and MAP-T. After several rounds of discussions, Rinse could not convince them to support these transition techniques. Yannis asked about the details of the deployment scenario. Rinse replied that they were using CGNAT, so the user was getting an internal IP address, a 164 address, and they were planning to assign the customers a v6 prefix as well. Thomas Schäfer, LMU, asked about the number of users who were already using IPv6 in their network. Rinse answered that they currently had about 50 friendly users (test users). Thomas added that it would be better to bypass internal services with IPv6. Rinse agreed and said that IPv6 was the way to go and that they already had a plan for it. Branimir Rajtar, 5x9 Networks, asked if they had implemented IPv6 in the core network as well or if they used 6PE/6VPE. Rinse answered that everything was dual-stack since day one in both the core and access networks. Peter Hessler, Globalways GmbH, said that the community should encourage people to deploy IPv6 whenever they were ready for it. Brian Storey, Gamma Telecom Limited, asked how long it had taken to reach this state and how they envisioned documenting IPv6 for their customers. Rinse answered that they hope by the end of this year 20% of the users will be IPv6 enabled, and next year it may be 80-100%. Peter Head, Gigaclear, asked for more elaboration on why they filtered the DHCPv6 releases. They decided to follow it up offline. 1. Clear Guidance for Implementing IPv6 in Enterprises Wilhelm Boeddinghaus The presentation is available at: https://ripe86.ripe.net/wp-content/uploads/presentations/123-RIPE86-IPv6-Wi… Wilhelm Boeddinghaus emphasized the need for clear guidance on IPv6 deployment phases, challenges, and steps, especially for enterprise IT departments. He asked the question, "Can we as the community provide this clear guidance to the enterprises?" Peter Hessler said that he liked the idea and mentioned that it would be hugely beneficial to a lot of enterprises. Marco Davids, SIDN Labs, asked if Wilhelm agreed with him that the working group should also work on getting IPv6 knowledge into schools and universities so that young students have at least some knowledge. Wilhelm agreed. He emphasized that students in universities were still learning IPv4, and we needed to educate young people about IPv6. An audience speaker said that it was not only enterprises but also ISPs who needed to learn about this. He claimed that even big ISPs do not know how IPv6 works. Wilhelm agreed but also claimed that enterprises had many more problems since their core business was not IT. Urban Suhadolnik, TU Graz, agreed with the previous comments about universities. Wilhelm emphasized once again that universities should involve themselves much more in this. Gert Doering, SpaceNet AG, agreed and thanked Wilhelm for bringing up enterprise problems regarding IPv6 transition into the meeting. He added that he would like to help with the new BCOP for enterprises. He said that it will not be easy to pick up and agree on the right solution, but that it should be tried. Wilhelm agreed and said we should also involve enterprise admins in our group. Benedikt Stockebrand said that since most IT people in academia didn't receive any network training at all, it was still the RIPE community's job to spread the word at a level that people without a proper IT background can handle. Jen contributed to this with another online comment indicating that as the adoption of IPv6 increases among enterprises, universities will offer more. Peter Hessler said that for some ISPs, it was not even an option to provide IPv6 connections to enterprises. An audience speaker thanked Wilhelm for his proposal, mentioning how important it was for enterprises. He also said that he would be open to writing, reviewing, and working on documents of the best resources for newcomers and beginners in IPv6 and TCP/IP. Jen mentioned another online comment. Markus said that his students were unwilling to learn IPv6 since they think nobody used it. Jen said that there were different approaches to this depending on the availability of IPv6 in each part of the world. Finally, Jen asked what the next action should be. Wilhelm said that he would send an email to the mailing list to start working on this with people who can contribute. 1. Implications of IPv6 Addressing on Security Operations Fernando Gont The presentation is available at: https://ripe86.ripe.net/wp-content/uploads/presentations/119-ripe86-fgont-i… Fernando Gont presented about the challenges of IPv6 security deployment. He also explained how IPv4 and IPv6 differ in terms of security implementations. Rinse Kloek mentioned that he conducted extensive CPE testing. One issue he encountered was that occasionally services were listening on local addresses, and if one copied the v4 test to the v6 test, it was possible to overlook this aspect. Fernando agreed and said testers did not know about ULA addresses. Benedikt Stockebrand suggested that leaving the IPv4 way of thinking would made things much easier. He added that not using dual-stack would simplify the way of working. Peter Hessler noted that a common mistake while translating IPv4 ACLs into IPv6, which was blocking ICMP as it should not be blocked in IPv6. Jen asked why it was important to care about the size of the prefix you block if it was someone else's network. Fernando answered that he experienced this in a meeting with a large content provider where they were just blocking a single IPv6 address instead of the /64. Fernando added that these kinds of things, which were obvious to this group, might not be obvious to the groups that were implementing rules in the networks. Jen added that with IPv4, it was much worse since you might be blocking many innocent users behind CGN just by blocking a single IPv4 address. 1. Conclusion & Thanks Benedikt Stockebrand announced that his term as the WG chair was ending with the next RIPE meeting, and that he did not want to go for another term. He asked the community if anyone was interested. As the last topic of the WG, Ondrej Caletka, RIPE NCC, asked everybody to test the IPv6-only network and try to identify any issues and report them to the vendors. Raymond , Benedikt, Jen. For Internal Use Only

1 0

Re: [ipv6-wg] Clear Guidance for Enterprises
by Gert Doering 04 Jun '23

04 Jun '23

Hi, On Sat, Jun 03, 2023 at 07:53:48PM +0000, Ole Troan (otroan) wrote: > Thought experiment. > IPv6 wasn?t invented. > Would we be able to make IPv4 continue to roll down the hill for another 25 years? Whether there's 3 or 4 layers of NAT won't matter much... everything that is not TCP or UDP won't survive, but since The Browser Oligopol seems to be set to move everything into QUIC anyway, we should be fine... It will nicely kill everything that is not Cloud or Rendezvous-Server- based, but there's quite a few parties outside that would consider this a feature. So yes. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

1 0

(IETF I-D) Implications of IPv6 Addressing on Security Operations (Fwd: New Version Notification for draft-ietf-opsec-ipv6-addressing-00.txt)
by Fernando Gont 02 Jun '23

02 Jun '23

Folks, The IETF OPSEC WG has adopted our IETF I-D entitled "Implications of IPv6 Addressing on Security Operations". This is the same material I presented at the last IPv6 WG meeting in Rotterdam (https://ripe86.ripe.net/programme/meeting-plan/ipv6-wg/). The IETF-ID is available at: * TXT: <https://www.ietf.org/archive/id/draft-ietf-opsec-ipv6-addressing-00.txt> * HTML: <https://datatracker.ietf.org/doc/html/draft-ietf-opsec-ipv6-addressing> We have tried to make the document as practical as possible for anyone doing security operations. Your comments and suggestions will be highly appreciated. P.S.: Thanks to those of you that sent feedback for previous revision of this document, by the way! Regards, Fernando -------- Forwarded Message -------- Subject: New Version Notification for draft-ietf-opsec-ipv6-addressing-00.txt Date: Fri, 02 Jun 2023 07:26:18 -0700 From: internet-drafts(a)ietf.org To: Fernando Gont <fgont(a)si6networks.com>, Guillermo Gont <ggont(a)si6networks.com> A new version of I-D, draft-ietf-opsec-ipv6-addressing-00.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-ietf-opsec-ipv6-addressing Revision: 00 Title: Implications of IPv6 Addressing on Security Operations Document date: 2023-06-02 Group: opsec Pages: 13 URL: https://www.ietf.org/archive/id/draft-ietf-opsec-ipv6-addressing-00.txt Status: https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-addressing/ Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-opsec-ipv6-addressing Abstract: The increased address availability provided by IPv6 has concrete implications on security operations. This document discusses such implications, and sheds some light on how existing security operations techniques and procedures might need to be modified accommodate the increased IPv6 address availability. The IETF Secretariat

1 0

IPv6-mostly IPv6-only(with dns64/nat64) dual stack at RIPE-meeting
by Thomas Schäfer 27 May '23

27 May '23

Hi, during the closing plenary were considerations to remove the IPv6-only(with dns64/nat64) network/ssid the next time. I would vote for that. IPv6-mostly covers the traditional IPv6-only. Someone made the proposal to provide a real "ipv6 only" net/ssid instead (without nat64) My first thought was: Never, it will the people just frustrate. My second thought was: Let's try it! After the first shock - only 50% of the websites support IPv6 - we should provide tips for testing: - using public dns64 with own nat64 address space - VPN, the public ones like apple privacy relay, cloudflare warp ... - VPN, own organisation/company like eduvpn for NREN (e.g. DFN supports it, other institutes too, cisco anyconnect... -VPN personal, like wireguard/ipsec to AVMs fritzbox and others, openvpn NAS/ own setups Last but not least I propose to provide that special DNS-resolver: https://gitlab.com/miyurusankalpa/IPv6-dns-server It increases the amount of IPv6 capable destinations. Regards, Thomas

4 3

FW: [address-policy-wg] IPv6 policy - 2nd prioritisation and outcomes discussion webinar
by Raymond Jetten 27 Mar '23

27 Mar '23

Just to let the IPv6WG know, there is an ongoing discussion on the next steps in IPv6 policy work at the Address Policy working group please see below for details, and of course feel free to participate in this important matter. Rgds, Ray For Internal Use Only -----Original Message----- From: address-policy-wg <address-policy-wg-bounces(a)ripe.net> On Behalf Of Leo Vegoda Sent: tiistai 21. maaliskuuta 2023 23.48 To: address-policy-wg(a)ripe.net Subject: [address-policy-wg] IPv6 policy - 2nd prioritisation and outcomes discussion webinar At RIPE 85 we continued a review of the IPv6 policy that began at RIPE 83. Several areas for improvement were agreed. We promised to host an inter-sessional webinar to discuss priorities and the outcomes to work towards. We held the first webinar on Monday, 20 February 2023. You can read a summary of what was discussed on RIPE Labs. A full recording and minutes are published on the interim sessions page. - https://labs.ripe.net/author/leo_vegoda/next-steps-in-ipv6-policy-work/ - https://www.ripe.net/participate/ripe/wg/active-wg/ap/interim-sessions The second webinar will take place on Tuesday, 11 April at 13:30 UTC (15:30 CEST). If you want to help us set priorities and define the outcomes the community needs you are welcome to join. Join Zoom Meeting https://ripe.zoom.us/j/93730573273?pwd=eWJ1WEEzSzVSSEJNKy9JeXk0L3RqZz09 Leo Vegoda for the Address Policy WG co-chairs -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg

1 0

Call for presentations IPv6 WG @RIPE86
by Raymond Jetten 27 Mar '23

27 Mar '23

Hello All, RIPE 86 will take place from 22-26 May 2023 in a hybrid format in which online and onsite participants can interact with each other using a common platform. The onsite event will take place in Rotterdam, Netherlands. For both cases you can register here: https://ripe86.ripe.net/attend/register/ The IPv6 Working Group session is scheduled for Thursday 25 May from 11:00 . 12:30 (UTC+1) (however it still may change) 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 online or onsite, and the duration of your presentation, and a short description of it. Once we have decided on the agenda, we'll contact the presenters. Hope to see many of you, On behalf of the IPv6-WG Benedikt, Jen, Ray For Internal Use Only

1 2

(IETF I-D): Implications of IPv6 Addressing on Security Operations (Fwd: New Version Notification for draft-gont-opsec-ipv6-addressing-00.txt)
by Fernando Gont 05 Feb '23

05 Feb '23

Hi, All, Recently, I happened to participate in an IPv6 deployment meeting with some large content provider, and said meeting included a discussion about how to mitigate some attacks using block-lists. These folks argued that they ban offending IPv6 addresses as /128s, following IPv4 practices. So it seemed to me that some of the implications arising from the increased IPv6 address space were non-obvious to them. -- that has been the motivation for the publication of this document. * TXT: https://www.ietf.org/archive/id/draft-gont-opsec-ipv6-addressing-00.txt * HTML: https://www.ietf.org/archive/id/draft-gont-opsec-ipv6-addressing-00.html Comments welcome! P.S.: The document is targeted at the IETF opsec wg (https://www.ietf.org/mailman/listinfo/opsec), but I'll be happy to discuss it on this mailing-list, off-list, or at the opsec wg mailing-list... Thanks! Regards, Fernando -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-opsec-ipv6-addressing-00.txt Date: Thu, 02 Feb 2023 19:48:40 -0800 From: internet-drafts(a)ietf.org To: Fernando Gont <fgont(a)si6networks.com>, Guillermo Gont <ggont(a)si6networks.com> A new version of I-D, draft-gont-opsec-ipv6-addressing-00.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-opsec-ipv6-addressing Revision: 00 Title: Implications of IPv6 Addressing on Security Operations Document date: 2023-02-02 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/archive/id/draft-gont-opsec-ipv6-addressing-00.txt Status: https://datatracker.ietf.org/doc/draft-gont-opsec-ipv6-addressing/ Htmlized: https://datatracker.ietf.org/doc/html/draft-gont-opsec-ipv6-addressing Abstract: The increased address availability provided by IPv6 has concrete implications on security operations. This document discusses such implications, and sheds some light on how existing security operations techniques and procedures might need to be modified accommodate the increased IPv6 address availability. The IETF Secretariat

1 0

New on RIPE Labs: IPv6 Policy Is a Community Self-Governance Success Story
by Alun Davies 30 Jan '23

30 Jan '23

Dear colleagues, The RIPE Address Policy Working Group invites the community to join the conversation on the next phase of IPv6 policy. In this new article on RIPE Labs, Leo Vegoda talks about the success of the policy so far and the process that is underway in order to determine whether there’s need for change: https://labs.ripe.net/author/leo_vegoda/ipv6-policy-is-a-community-self-gov… Best regards, Alun Davies RIPE Labs Editor RIPE NCC

1 0

Pv6 policy - prioritisation and outcomes discussion webinar
by Raymond Jetten 27 Jan '23

27 Jan '23

Dear IPv6-WG list members, Below an invite from the Address Policy Working Group, to an IPv6 address policy webinar. Kind regards, Ray From: Leo Vegoda <leo(a)vegoda.org> Date: Thu, 26 Jan 2023 at 10:14 Subject: IPv6 policy - prioritisation and outcomes discussion webinar To: <address-policy-wg(a)ripe.net> At RIPE 85 we continued a review of the IPv6 policy that began at RIPE 83. Several areas for improvement were agreed. We promised to host an inter-sessional webinar to discuss priorities and the outcomes to work towards. The identified areas for improvement include: - Better guidance on documentation requirements for large allocations - Simpler language for the HD-ratio - Make it easier for small networks to assign a few addresses to other organisations - Ensure allocations always fall on a nibble boundary If you wants to help us set priorities and define the outcomes the community needs you are welcome to join. Monday, 20 February 2023 at 13:00 UTC (14:00 CET). Join Zoom Meeting https://ripe.zoom.us/j/94307989734?pwd=YytnQm53SjJEWUtKemxQM3dGcjZmQT09 Meeting ID: 943 0798 9734 Passcode: 339420 Leo Vegoda for the Address Policy WG co-chairs For Internal Use Only

1 0

Re: [ipv6-wg] [Snac] [v6ops] "router cascade with DHCPv6-PD"
by Michael Richardson 22 Jan '23

22 Jan '23

Ole Trøan <otroan(a)employees.org> wrote: >>>> The lack of a standardized way to communicate DHCPv6-server PD to >>>> DHCPv6-relay, and the expectation that the relay would just *snoop* = >>>> on the >>>> DHCPv6-PD contents has bugged me for a long time. If we are going to >>>> recommend that they act as relays, then I'd like to fix that. >>> If DHCP is used for prefix assignment inside of a site, the relay does >>> not need to do route injection for the requesting router. The RR can >>> simply advertise the assigned prefix in routing. >> >> a) it's actually cross-site. > Elaborate please. We have three entities. 1) the STUB router or other downstream "home" router. 2) the CPE router which is at the "north" side of the home LAN, and on the south side of the WAN/DSL/CMTS link. 3) The ISP DHCP server which is somewhere inside the ISP, with a DHCP relay at the BMS or Cable Head end to send to it. If (2) treats a DHCP-PD request from (1) as a relay, then it would relay to (3), which would allocate a new prefix. That message would back through (3) [where it gets snooped on, and maybe, yes, injected into the ISP routing system]. Then it would relayed to (2), which would then relay it to (1). (2) has to do something to route the prefix to (1), which today, means snooping on the results. But, even if the (2) is operated by the ISP, it's not part of the ISPs site. The south side of (2) belongs to the home owner. The prefix needs to be routed from (2) to (1). There is no routing protocol in the home at this time(alas!), so there is nothing to "inject" it into. -- Michael Richardson <mcr+IETF(a)sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide

1 0

Re: [ipv6-wg] [Snac] [v6ops] "router cascade with DHCPv6-PD"
by Michael Richardson 18 Jan '23

18 Jan '23

Ole Trøan <otroan(a)employees.org> wrote: >> The lack of a standardized way to communicate DHCPv6-server PD to >> DHCPv6-relay, and the expectation that the relay would just *snoop* on the >> DHCPv6-PD contents has bugged me for a long time. If we are going to >> recommend that they act as relays, then I'd like to fix that. > If DHCP is used for prefix assignment inside of a site, the relay does > not need to do route injection for the requesting router. The RR can > simply advertise the assigned prefix in routing. a) it's actually cross-site. > Ah, you don’t want to run a routing protocol? Well, there’s your problem. b) If you can find a way to deploy OSPFv3 (or BABEL) in every home network, then I'm game. -- Michael Richardson <mcr+IETF(a)sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide

1 0

Re: [ipv6-wg] [Snac] [v6ops] "router cascade with DHCPv6-PD"
by Michael Richardson 17 Jan '23

17 Jan '23

(Hi Martin, I'm just the messenger, your questions are all pretty good. For others, I think it was not obvious that they are about draft-winters-v6ops-cpe-lan-pd-00. But, more than my brain can handle right now) Ted Lemon <mellon(a)fugue.com> wrote: >> Why not honor the IA_PD size requested by the requesting router? Do you >> expect that possible another cascade router would be switched to DHCPv6 >> relay mode? > What’s the use case for this behavior? And yes, we expect routers to act as > DHCPv6 relays. I think that actually we've created an ambiguity about whether they are DHCPv6 relays or if they are full DHCPv6 servers. There are arguments both ways, and in some cases the choice is transparent to the end system, but in other ways it is not. The lack of a standardized way to communicate DHCPv6-server PD to DHCPv6-relay, and the expectation that the relay would just *snoop* on the DHCPv6-PD contents has bugged me for a long time. If we are going to recommend that they act as relays, then I'd like to fix that. Either way, Tim's v6ops draft-winters-v6ops-cpe-lan-pd-00 should clarify. LPD-1 suggests the IPv6 CE Router is a server, not a relay. -- Michael Richardson <mcr+IETF(a)sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide

2 1

"router cascade with DHCPv6-PD"
by Michael Richardson 15 Jan '23

15 Jan '23

(I guess the article is in German, but google translate did a good job on it) This relates to the desire to amend RFC7084 to support "southbound" DHCPv6-PD: https://datatracker.ietf.org/doc/draft-winters-v6ops-cpe-lan-pd/ >https://www.heise.de/select/ct/2023/2/2230709000622055021 > >Alexander Traud tested 29 CPEs and tried to understand how they react to prefix changes. Router cascade with DHCPv6-PD With routers connected in a cascade, the internal network can be divided into several zones. This is useful, for example, in shared apartments that want to share an Internet connection, but each resident should still have their own (W)LAN. To do this, the front router, which is directly connected to the Internet, must pass on part of the prefix it received from the provider (DHCPv6-PD, prefix delegation) and its DHCPv6 server must ideally be able to use DHCPv6 reconfigure. Only AVM and Wavlink offered both in the test field. -- Michael Richardson <mcr+IETF(a)sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide

2 2

IPv6 martian filter-set
by Nia Provia 12 Jan '23

12 Jan '23

Hi all, we want to update our BGP filtering with ipv6 martians prefixes. Querying RIPE database I am seeing two different filter-set regarding martians v6 : fltr-martian6 --> last-modified : 2015-07-28T13:39:28 fltr-martian-v6 ---> last-modified: 2020-09-10T23:40:02 Is there any recommendation/suggestion whether I should use any of these filters ? and if yes , which one ? Regards Nia

3 2

Advice for IPv6 only network /Network elements
by Agshin N 02 Jan '23

02 Jan '23

Hello, To Whom it may concern, We are small group which planning to build IPv6-only network as ISP. Legal activity started. We did some internet research and network logic topology. Nevertheless are looking best practice IPv6-only network as deployment and therefore need advice who already did it. We may send drawing topology if needed for advising. May we ask someone who is good for IPv6-only Central (data center) part implementation as router (BGP, PLAT), NAT64/DNS64, DHCPv6 sever and Translation part as well as suggestions ? Access fully are going to be FTTH and as start 3K Houses planned Namely which hardware and Software needs for it ? With Happy New 2023 Year! -- Respectfully Agshin N Skype:nagshin UTC/GMT +4 hours - Classified as Confidential -

1 0

Windows 11 now implements RFC 7217 (stable privacy addresses)!
by Fernando Gont 13 Dec '22

13 Dec '22

Folks, After over 10 (yes, *ten*) years, we have finally addressed security/privacy issues in the generation of IPv6 stable addresses in most popular operating systems. The traditional scheme/algorithm to generate stable IPv6 addresses with SLAAC required that the underlying MAC address be employed to generate the Interface Identifier. That is, the underlying MAC address would be embedded in the lower bits of an IPv6 address. This scheme allowed for host-tracking (since MAC addresses are usually globally-unique), address scanning (since addresses will follow specific patterns) and a number of other issues. In 2011, I submitted an IETF Internet-Draft proposing a scheme for generating stable addresses with SLAAC, meant to replace the traditional scheme. The scheme could be summarized and simplified as: Interface_ID = Hash(Prefix, Secret). Thus, interface identifiers would be stable within the same subnet, but vary across subnets. [Replacing the traditional scheme with this new scheme was anything but easy -- if you're curious, please check the "IPv6 Addressing" section in <https://www.si6networks.com/2020/08/06/a-brief-history-of-recent-advances-i…> ] Over time, popular operating systems and packages adopted the proposed algorithm: the Linux kernel, NetworkManager, OpenBSD's slaacd, MacOS, etc. Eventually, virtually every popular OS had adopted the scheme.... except Windows. Based on a recent note by Brian Carpenter, I ended up testing Windows 11, and I can confirm that it does implement RFC 7217 / RFC 8064! Therefore, e.g. if multiple prefixes are employed on a subnet, the stable addresses for each of such prefixes will employ a different Interface Identifier, thus avoiding the security/privacy issues discussed above -- this is really good news! Unfortunately, Windows still generates temporary addresses with the algorithm specified in RFC 4941, thus resulting in all temporary addresses for a given interface employing the same Interface Identifier (!). This problem has been addressed in RFC 8981... but it's implementation is not yet widespread, yet (it has been incorporated in e.g. the Linux kernel, though). I just hope it doesn't take Windows and others yet another 10+ years to implement RFC 8981, to finally address the remaining security/privacy issues in IPv6 address generation! [Original article with screenshots: https://www.linkedin.com/posts/fernandogont_after-over-10-yes-ten-years-we-… ] Thanks! Regards, -- Fernando Gont SI6 Networks e-mail: fgont(a)si6networks.com PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494

2 1

Minutes from RIPE 85 IPv6 WG
by Raymond Jetten 17 Nov '22

17 Nov '22

Dear list members, here are the draft minutes from RIPE 85 IPv6 wg. Please share your comments or remarks to the list so they can be adjusted. The minutes will otherwise be published in two weeks IPv6 Working Group Minutes - RIPE 85 Wednesday, 26 Oct 2022, 12:00-13:00 (UTC+2) WG co-Chairs: Benedikt Stockebrand, Raymond Jetten Scribe: Oleg Muravskiy Status: Draft Welcome, Etiquette, Approving Minutes, Co-Chair Selection IPv6 Working Group Co-Chairs Raymond reminded participants about the Code of Conduct. The RIPE 84 minutes were approved. Benedict announced that Raymond's term as co-chair had ended, but that he was happy to continue in that role. There were no further nominations or objections, so Raymond was re-appointed as co-chair. Path Tracing Pablo Camarillo, Cisco Systems This presentation is available at: https://ripe85.ripe.net/wp-content/uploads/presentations/76-20221026-RIPE85… Pablo described the recent implementation of an addition to the IPv6 packet header extension that records the path of packets in ECMP networks and presented the use cases that were enabled by this feature. Leandro Bertholdo, University of Twente, asked how this addition was different from the IPv4 registration option. Pablo replied that the main difference in this approach was that they recorded the information at the line speed of the basic packet forwarding pipeline, and used only 3 bytes for each node. Leandro asked the presenter if they recorded an ID of the router that the packet passed. Pablo replied that they recorded a sequence of interface ID. Leandro asked if it was for the input interface or the output. Pablo replied that they recorded an ID of the output interface at each one of the routers Alexander Azimov, Yandex, asked if this would work in the MPLS core. Pablo said that this was possible, but that for the moment it was only implemented for IPv6. Open Source NAT64 Implementations Nico Schottelius, ungleich This presentation is available at: https://ripe85.ripe.net/wp-content/uploads/presentations/74-ripe85-open-sou… Nico showed a comparison of different open source implementations of NAT64, and asked the audience to provide more feedback and point out implementations they missed. Jan Žorž, 6connect, asked Nico if they had tried a VPP implementation as it was very fast. Nico said that he hadn't but that it was nice to know about it. Urban Suhadolnik, University of Ljubljana, asked if the presenter knew of any CLAT implementation, possibly for Windows, as the user-space implementation of CLAT was missing. Nico said that he couldn't answer the question as he was not familiar with this the topic. Deploying IPv6-Mostly Access Networks Ondřej Caletka, RIPE NCC This presentation is available at: https://ripe85.ripe.net/wp-content/uploads/presentations/9-RIPE85-Deploying… Ondřej presented an "IPv6-mostly" network that was implemented at this RIPE Meeting, which combined IPv6 functionality only for devices that supported it, and traditional dual-stack for other devices, all in the same network. Leonard Wagner, IN-Berlin e.V, asked since which Android PREF64, DHCP option 108 and CLAT were supported. Ondřej replied that version 11 and above were supported by the vendor, but that he was not sure about older versions. Michael Richardson, one of the authors of the IPv4-only option, noted that when he developed this feature he never imagined that people would deploy it on DHCP servers and not change anything. He added that it was interesting to see how it worked because they assumed that DHCP servers would not allocate addresses and therefore would not run out of addresses in the pool. So it was cool to see that it just worked without doing that. He further said that for any connect, if the client was v4-only, and was just creating a v4-only UDP encapsulated thing that the local end of course had no idea what to do with, it had to be encapsulated in a v6 packet to send it. He added that he thought CLAT would be of no help but that it might work on Mac OS but not on other systems. He mentioned that IOS would never work until it went to v6 and that the Cisco people should be embarrassed about this. Veronika McKillop, UK IPv6 Council, asked which DHCP servers supported RFC8925. Ondřej replied that this was option 108 and that Kea, at least, did not support it. He added that there were two options. If you have enough addresses for the IPv4 pool, any server that allowed setting a custom option could be used. If there was any special support for this feature, the server would simply respond with option 108 and not allocate an address from the pool. He stated that he was not aware of such an implementation, as even Kea cannot be used in this way. He added that if the pool was empty, it would not even respond and that this was an interesting feature to implement for DHCP server producers. Jordi Palet Martínez, The IPv6 Company, said that it was worth mentioning that most of the CLAT implementations just used a default NAT64 prefix (the WKP). He added that there was only a single translation when using the CLAT and that two translations were only needed if there were no DNS64 (https://datatracker.ietf.org/doc/rfc8683). He said that even if your network was using NAT, NAT64 would also work well. Radek Zajic via Meetecho shared that the CLAT on iOS 16 also worked in apps requiring unix/raw sockets too (e.g. Hurricane Electric Network Tools can ping IPv4-only targets via the CLAT). Ondřej thanked Radek for his comment. Round Up and Thanks IPv6 Working Group Co-Chairs Raymond thanked all participants and the RIPE NCC and closed the session. For Internal Use Only

1 0

SLAAC and Broadcast RA
by Xuo Guoto 02 Nov '22

02 Nov '22

Dear WG, Apologies if this mail is off topic here. I have a question about BCOP-690 wrt SLAAC BCOP-690 says: Using a /64 prefix from a dedicated pool of IPv6 prefixes is the most common scenario and currently the best practice. A separate block of IPv6 space is allocated for the WAN links to the end customer CPEs, so that when CPE connects to the network and performs router discovery, a /64 prefix is used to number both ends of the connection. My understanding of this recommendation is that in an ISP scenario, each RG will be assigned a seperate /64 prefix for CPE WAN. The ISP BRAS or BNG is also expected to send periodic multicast RA. My question is how a multicast RA can be sent to a VLAN, in which each RG is expected to have a different /64 prefix? R-43 of TR-177 says: The BNG MUST be configurable to send multicast RA messages that do not contain a Prefix Information Option (PIO), in order to advertise the default router address. R-44 says: The BNG SHOULD support sending periodic and solicited multicast RA messages having the unicast MAC address of the RG or of the hosts behind a bridged RG (see RFC 6085 [26]). Reading these two together, is it correct to say that BNG should be sending out periodic multicast RA without PIO, but RA with PIO should be sent only as a reply to an RS message from RG, with multicast IPv6 destination address but with unicast link-layer address of RG. Thanks and Regards, X.

1 0

IPv6 for Dutch email servers
by Michael Richardson 28 Oct '22

28 Oct '22

A few years ago there was a presentation about getting IPv6 MX setup for various Dutch entities: Municipalities, Hospitals, etc. I couldn't find this in the agendas for the past ten RIPE meetings for IPv6. Maybe it was in a plenary. I think it was pre-pandemic. I wondered (I am suggesting) that maybe an update on this effort would be timely? -- Michael Richardson <mcr+IETF(a)sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-

5 6