- ipv6-wg - mailman.ripe.net

A strange idea
by Jens Link 05 Mar '24

05 Mar '24

Hi, last Monday there was an event by https://www.eco.de titled "IPv6 in Germany - How do we help those who are hesitant?" It was a nice day but unfortunately very few of the hesitant people where there. As I'm also currently working in a rather big IPv6 project IPv6 know how and training is currently a big topic in my daily work. As I was just randomly watching youtube, I had a very strange idea: What if we put together an "advent of IPv6" just like https://adventofcode.com/ or https://tryhackme.com/r/christmas We would need to create 25 tasks for people to solve. From basics to more advanced topics. What we also need is a containerized lab environment, including some virtual networking stuff. And maybe some sponsors for e.g. T-Shirts for people completing all / most of the task. And maybe some nice certificate. People seem to like them. Jens -- ---------------------------------------------------------------------------- | Delbrueckstr. 41 | 12051 Berlin, Germany | +49-151-18721264 | ----------------------------------------------------------------------------

3 4

IPv6 resources
by Jens Link 05 Mar '24

05 Mar '24

Not sure if I send this to this list. Last year I started working in a new IPv6 project and needed a place to collect some links. So here we go: https://gitlab.com/jenslink/ipv6-resources/ Fell free to send merge requests. Jens -- ---------------------------------------------------------------------------- | Delbrueckstr. 41 | 12051 Berlin, Germany | +49-151-18721264 | ----------------------------------------------------------------------------

1 0

Call for IPv6 WG Co-Chair candidates
by Raymond Jetten 04 Mar '24

04 Mar '24

Dear IPv6 Working Group, Jen Linkova, who has been one of the co-chairs of the IPv6 Working Group since RIPE 69 has announced she wishes to step down at the RIPE 88 meeting in Kraków, at the end of her term. Thus, we have a call for candidates. The term of a IPv6 WG co-chair is three years. A current co-chair may stand for re-selection at the end of their term or may resign voluntarily at any time. What is the IPv6 WG 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. 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 ipv6-wg-chair at ripe.net mailto:ipv6-wg-chair at ripe.net<mailto:ipv6-wg-chair%20at%20ripe.net> We kindly request you to respond at latest Friday 3-May-2024 midday CET (Amsterdam), when the call for candidates will be closed. After this we will announce the candidates on the list, and you can express your support or concerns. However the official selection will take place at the RIPE 88 Meeting in Kraków during the IPv6 Working Group session. On behalf of the IPv6 WG co-chairs, Ray RIPE IPv6 Working Group co-Chair To the co Chairs: ipv6-wg-chair at ripe.netmailto:ipv6-wg-chair at ripe.net<mailto:ipv6-wg-chair%20at%20ripe.net> To the mailing list: ipv6-wg at ripe.netmailto:ipv6-wg at ripe.net<mailto:ipv6-wg%20at%20ripe.net> For Internal Use Only

3 2

How do I get a public static IPv6 address?
by Turritopsis Dohrnii Teo En Ming 03 Mar '24

03 Mar '24

Subject: How do I get a public static IPv6 address? Good day from Singapore, When I signed up for static IP address with my internet service provider, I only managed to get a public static IPv4 address. How do I get a public static IPv6 address? Thank you. Regards, Mr. Turritopsis Dohrnii Teo En Ming Targeted Individual in Singapore

4 5

IPv6 Working group call for presentations for RIPE88
by Raymond Jetten 06 Feb '24

06 Feb '24

Hello All, RIPE 88 will be held in Krakow, Poland from 20-24 May 2024, as well as online. For any participation form you can register here: https://ripe88.ripe.net/attend/register/ The IPv6 Working Group session is scheduled for Thursday 23 May from 11:00 . 12:30 (UTC+1) 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 closer to the meeting. Hope to see as many of you as possible, On behalf of the IPv6-WG Christian, Jen, Ray For Internal Use Only

1 0

Czech government announced IPv4 end date
by Christian Seitz 31 Jan '24

31 Jan '24

Dear IPv6 WG members, some of you might already have read this, but I would like to bring it to the attention of our working group: Last week the Czech government approved a resolution, that they will stop providing government services over IPv4 starting on 2032-06-06 [1]. This is point number 14, translated in english with the help of a translator as I don't speak czech ;-) --------------------CUT-------------------- 14. Restarting the introduction of DNSSEC technology and the IPv6 protocol in the state administration, no. 25/24 Submitted by: Minister of Industry and Trade Result of the government meeting: approved . --------------------CUT-------------------- There is also some more information in blog articles of nic.cz [2] [3]. The end of IPv4 is near [4] (tm). A link to the details of the resolution (in czech) is also on that page. I hope that this announcement of the Czech government will speed up the IPv6 adoption. Ok, it's still 8 years until 2032, but there are also a lot of companies out there who did not even think about implementing IPv6 yet. What is your opinion about this? [1] https://vlada.gov.cz/cz/media-centrum/aktualne/vysledky-jednani-vlady-17--l… [2] https://blog.nic.cz/2024/01/18/kratke-vlny-vladni-restart-podpory-ipv6/ [3] https://blog.nic.cz/2024/01/18/odvazny-krok-ceske-vlady/ [4] https://konecipv4.cz/en/ Kind regards from Berlin Chris

2 2

Question about how I handle web sites in my IPv6 survey
by Mark Prior 02 Jan '24

02 Jan '24

Hi there, I'm seeking some views on how I should report some web failures on my IPv6 survey page <https://www.mrp.net/ipv6_survey/>. If a site has both A and AAAA records for a web site I will try to connect to the IPv6 address and see if there is a web site listening there. It will start at tcp port 80 and then follow any redirects until hopefully it finds a 200 response. The cases where it gets to a 200 are fine as that's "success" but there are some failure modes that I can't really make my mind up on so having some feedback would be potentially useful. In all these cases I see a site with A and AAAA records so I connect on port 80 of the IPv6 address(es). 1. If the connection fails should I just report that or should I do anything more? For example see if the site responds via IPv4. 2. If the connection succeeds (so I assume there should be a working IPv6 based web server) but after querying it with a HTTP/1.1 message sees the site resets the connection (or fails in some other manner). 3. The connection succeeds as does the query and I get a 301 redirect to a location that fails to connect (typically it's the https port but could be another domain name). Again is this enough or should it do something else? The difference is in how they are reported on the main survey page. If there is a problem then the cell will be blue but if I stop at the error then some indication of the error will appear in the cell. If after the failure I check if IPv4 works then the cell will still be blue but the indication in the cell will be the IPv4 status (more often than not this is success and so the indicator is type of connection (HTTP, HTTPS, HSTS, H2, etc) with a link to the web page. At the moment I'm not consistent and I probably should be :-) but what type of indication is more helpful? Finally in some cases I'll get a HTTP status code such as 403, 429 or 503 rather than 200 and these are reported with a background of either light green or light red depending on whether it occurred on an IPv6 or IPv4 connection. Should these be blue rather than a different green/red? Thanks, Mark.

3 4

IPv6-WG draft minutes from RIPE87
by Raymond Jetten 02 Jan '24

02 Jan '24

Hello All, A happy new year to all of you ! below are the draft minutes from the RIPE87 meeting in Rome. A big thank you to Matt for taking the notes Please comment if you want any changes before Friday 12.1 Session: IPv6 Working Group RIPE 87 Date: Thursday, 30 November 11:00 - 12:30 (UTC+1) WG co-Chairs: Benedikt Stockebrand, Jen Linkova, Raymond Jetten Scribe: Matt Parker Status: Draft View the video archive<https://ripe87.ripe.net/programme/meeting-plan/ipv6-wg/> View the stenography transcript<https://ripe87.ripe.net/archives/steno/39/> View the chat archive<https://ripe87.ripe.net/archives/chat/39/> 1. Welcome Raymond Jetten, IPv6 Working Group Co-chair The presentation is available at: https://ripe87.ripe.net/wp-content/uploads/presentations/88-IPv6-WG-Opening… Raymond opened the session, welcomed the attendees and approved the minutes from RIPE 86. He also explained the process that would be followed for the upcoming Working Group Co-chair selection and reminded everybody to follow the microphone etiquette throughout the session. There were no questions. 2. Co-Chair Change Raymond Jetten, IPv6 Working Group Co-chair Benedikt Stockebrand stepped down as IPv6 Working Group Co-chair, having fulfilled the role for nine years. Raymond thanked Benedikt for his service. The two new candidates for the Working Group Co-chair role, Christian Seitz and Paolo Volpato, joined Raymond on stage. They briefly introduced themselves and explained to the Working Group why they would be a good choice for the role. A poll was conducted using Meetecho. There were no questions. 3. Currently Available Solutions to Provide IPv6-based Multi-homing Connectivity Paolo Volpato, Huawei The presentation is available at: https://ripe87.ripe.net/wp-content/uploads/presentations/82-IPv6-Multihomin… Paolo gave a high level summary of the work being carried out in the IPv6 Operations (v6ops) working group in the IETF, focussing specifically on support for multi-homing in IPv6. Gert Döring, SpaceNet AG, commented that his favourite model was the dual provider aggregatable prefix. Not only because it's less burden on the routing table, but also because it empowers the client machines to make decisions. He added that problems remain with source address selection and source address failover but that there is potential for bright solutions. Rinse Kloek, Delta Fiber, agreed with Gert and stated that he is not a big fan of using PI space for multihoming. This is due to the impact that it could have on the growth of the global routing table. Urban Suhadolnik, TU Graz, asked whether they had looked into mobile IP extension? Paolo replied that that they had not yet, but that it is something they can consider. Jan Zorz, 6connect, commented that if we use PA space, and one of the CPE dies, then the neighbor reachability protocol will take care of switching to the other gateway. He added that the source selection mechanism is still fundamentally broken, but work is ongoing at the IETF to address this. Finally, he recommended a draft from Jen Linkova to address the problem of a CPE coming back to life and receiving a different prefix. Jen stated that it is a functioning solution and Jan offered to help with the next steps. Jen Linkova, asked in her personal capacity, whether we should focus on a limited number of scenarios, covering perhaps 80% of our current use cases, rather than trying to consider all possible scenarios? Jen also responded to Jan's comment about host gateway tracking by stating that she believes both Microsoft Windows and Apple do this already, and that some work is happening on Linux. Once the Linux problem is solved most of the normal host operating systems will be covered. Brian Turnbow, twt spa, observed that he had received three different tenders over the last year where they had their own AS number and their own, de-aggregated, /48 assignment. He explained that the tenders came from multinational American companies who were assigning /48s worldwide to different sites, all from their own block. He commented that he had not seen it yet from any European companies. There were no further questions. 4. What's New on the IPv6 Front at the IETF? Eric Vyncke, Cisco The presentation is available at: https://ripe87.ripe.net/wp-content/uploads/presentations/102-20231130-RIPE-… Eric provided an update about what is new on the IPv6 Front at the IETF. Jan Zorz stated that he really likes the idea of prefix delegation to every host, if every host has a /64 you could run a web server on IP, so there would be no need for IP ports. Tom Hill, BT, commented that he is a co-author on the Trusted Domain SRv6 draft which is seeking an optional ether type for SRv6. He stated that the reason he did this is that the Micro-SID draft would allow you to forgo the SRH in the packet, which he found concerning. Jordi Palet Martinez, The IPv6 Company, mentioned that there is a draft being updated which is important to the community - RFC 7084, Basic Requirements for IPv6 Customer Edge Routers. Tobias Fiebig, MPI-INF, mentioned two additional drafts. The first is updating the DNS trans record requirements making IPv6 an equal citizen to IPv4, which Tobias commented was long overdue. The second deals with IPv4 via IPv6 next hops which we have for NLRI and BGP announcements. There were no further questions. 5. Deployment of 464XLAT in a Medium-sized Operator Jordi Palet Martinez, The IPv6 Company The presentation is available at: https://ripe87.ripe.net/wp-content/uploads/presentations/104-464XLAT-deploy… Jordi discussed his experiences deploying 464XLAT in a medium sized operator. Michael Richardson, Sandelman Software Works Inc, explained that one of the problems he had discovered with his dual-stacked network was troubleshooting IPv4 only customers. He asked Jordi whether he sometimes had to undo dual stack on them to find out what was broken? Jordi replied that it is sometimes necessary to disable either IPv4 or IPv6 to investigate a problem, but in general it wasn't too much of a problem. Rinse Kloek asked whether Jordi had found a CPE vendor that supported the CLAT part of 464XLAT. Jordi responded by stating that he is one of the authors of RFC 8585 (Requirements for IPv6 Customer Edge Routers to Support IPv4-as-a-Service) and that the other two authors are both vendors who support it. However, he agreed that it may be necessary to speak with the vendor regarding specific configuration requirements and mentioned that not all customers will be happy using open source for this. Urban Suhadolnik asked Jordi for clarification on the APNs with Apple that he mentioned. Is it correct that there is an OTA from Apple that updates them? Jordi replied that no, you need to have an OTA platform on your network. Urban stated that he was also asking for Android because the configuration is already there, it is in the OS when you get the phone. Jordi agreed that it is much easier in Android, if they see that they can choose IPv6 it just works, there is no need to change the PDP type manually. There were no further questions. 6. Thanks, Wrap Up and Rate the Talks [5 min] Raymond and Jen announced the result of the Working Group Co-chair selection, Christian Seitz was selected. Raymond reminded everybody to rate the talks at RIPE 87 and Jen asked the working group to submit talks for RIPE 88 in Krakow. The session was closed. For Internal Use Only

1 0

Allocating a /16 to a large enterprise ?
by Eric Vyncke (evyncke) 12 Dec '23

12 Dec '23

[This is about ARIN, but curious to see if anybody has any insight...] A colleague of mine showed me https://whois.arin.net/rest/net/NET6-2630-2, i.e., a /16 allocated by ARIN to Capital One (AFAIK a US bank). Of course, this may be a tool bug, or a human encoding mistake, else I will start to fear an IPv6 addresses exhaustion in the future (only 2**13 of /16 out of 2000::/3). If anyone has any insight, then I will welcome this insight in this specific case. Regards -éric

6 5

follow up on the IPv6-wg session at RIPE 87
by Raymond Jetten 07 Dec '23

07 Dec '23

Dear list Members, During RIPE 87 Benedikt Stockebrand has stepped down as IPv6 WG Co-Chair. Again Benedikt, on behalf of Jen and me thanks for the many years of having you. Jen and I decided to give Benedikt a small present after stepping down. A bottle of quality Italian wine, a wine bottle opener, a glass to drink from, and bag of popcorn. We had 2 candidates to fill Benedikt's place. Christian Seitz, and Paolo Volpato. We used Meetecho's poll as a platform where participants on site and remote could show their preference. The result was that Christian is now our new co-chair, Welcome Christian. We hope to see you all again in Krakow Poland next may. On behalf of Jen and Christian, Raymond Jetten RIPE IPv6 Working Group co-Chair To the co Chairs: ipv6-wg-chair(a)ripe.net<mailto:ipv6-wg-chair@ripe.net> To the mailing list: ipv6-wg(a)ripe.net<mailto:ipv6-wg@ripe.net> For Internal Use Only

1 0

The Candidates for the IPv6-wg Co-chair position
by Raymond Jetten 28 Nov '23

28 Nov '23

Dear IPv6-wg list members and RIPE community. In the upcoming RIPE meeting (RIPE87) we will select a new co-chair, who will fill the gap, since Benedikt Stockebrand has decided to step down and not run for another term. The selection process will be done at the IPv6-wg session, via the meeting system "Meetecho". There will be a poll on who do you want to select. This system is available for all onsite and online. You will all get a link from the meeting organization to the Meetecho website, keep it near... You can still register for the meeting online or onsite: https://ripe87.ripe.net/attend/register/ In response to our request on the list we are glad to announce that we have 2 interested candidates: Christian Seitz Paolo Volpato They will send in their personal motivations and backgrounds to this list soon. We would like the members of this list to show their support for their preferred candidate, or send questions to the candidates, so we can discuss this even before the meeting. The decision however will be made at the meeting as said before. Best regards, The IPv6 WG chairs. For Internal Use Only

7 6

]REPOST] Animation showing IPv6 growth over time.
by Raymond Jetten 13 Nov '23

13 Nov '23

Some very nice visuals, enjoy ! Subject: [118attendees] Animation showing IPv6 growth over time. Date: Mon, 06 Nov 2023 07:16:53 -0600 From: Nick Buraglio <buraglio(a)forwardingplane.net> Reply-To: Nick Buraglio <buraglio(a)forwardingplane.net> To: 118attendees(a)ietf.org This set of animations have made the rounds within some of the IPv6 groups at IETF and it was thought that the 118 participants may find it encouraging and interesting. These animations showing both the growth of IPv6 over time were compiled by a researcher named Barrett Lyon using data from RouteViews* data. The animation of v6 starts on May 9th, 2003, as that is when RouteViews began compiling their IPv6 data. Enjoy! IPv4 vs IPv6 Full: https://www.youtube.com/watch?v=vo5glK9czIE 1m social media: https://www.youtube.com/watch?v=tMyFRGGGWOQ IPv6 with labels Full: https://www.youtube.com/watch?v=jj9RjUtZ54o 1m social media: https://www.youtube.com/watch?v=jj9RjUtZ54o * https://www.routeviews.org/routeviews/ For Internal Use Only

1 0

Survey for operators on IPv6 Extension Headers
by Justin Iurman 06 Nov '23

06 Nov '23

Hi all, On behalf of the University of Liege (Belgium), we've been doing measurements on IPv6 Extension Headers over the last two years. More specifically, we're trying to evaluate how they are processed by routers along the path, and so from the edge. Now, we would like to compare our observations with the reality of operators. For that, we propose this very short survey [1] to operators and would really appreciate if you could complete it. Note that we guarantee anonymity of your answers by not sharing any data. Looking forward to your input. Thanks, Justin [1] https://docs.google.com/forms/d/e/1FAIpQLSeHgEWVQMrAbB9-pRf-T-mDHXxRxw-mAqO…

2 2

IPv6 survey web page
by Mark Prior 03 Nov '23

03 Nov '23

Hi all, Some folks in this WG may not know that I maintain a web page that shows accessibility to web, mail and DNS services via IPv6 across a number of domains. As I have just rewritten the script that generates it I thought I would take that opportunity to promote it a little. Back in 2007 at an Internet2 Joint Techs meeting Ron Broersma of DREN presented a talk on IPv6 adoption that included a coloured chart that showed a small number of Internet2 related domains and if they had IPv6 accessible web, mail and DNS. Basically the argument was that it was fine to have IPv6 plumbing but what were you doing with it (and the answer was not a lot). After chatting with Ron I decided to code up something and create a web page so I could report back any changes. Early in the piece the updates were ad hoc (probably driven by meeting deadlines) but eventually it was run by cron. Now it runs daily and works though a largish list of domains seeing if there are web, mail (smtp, submission and imap/pop), DNS, NTP, XMPP and SIP services available via IPv6. Also there is DNSSEC because something has to have worse deployment than IPv6 :-) Originally research and education domains dominated the list but over time I have added ISP/telcos and other commercial companies. There are probably zombie domains in the list too. Anyway that's enough of a background. If you are interested then have a look at <https://www.mrp.net/ipv6_survey/>. I am happy to add more domains if you want to suggest them. Regards, Mark.

1 0

Call for co-chair candidates for the IPv6-WG
by Raymond Jetten 02 Nov '23

02 Nov '23

Dear IPv6 Working Group, Benedikt Stockebrand, who has been one of the co-chairs of the IPv6 Working Group since RIPE 69 has announced he wishes to step down at the RIPE 87 meeting in Rome, at the end of his term. Thus, we have a call for candidates. The term of a IPv6 WG co-chair is three years. A current co-chair may stand for re-selection at the end of their term or may resign voluntarily at any time. What is the IPv6 WG 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. 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 ipv6-wg-chair(a)ripe.net<mailto:ipv6-wg-chair@ripe.net> We kindly request you to respond at latest Friday 10-November-2023 midday CET (Amsterdam), when the call for candidates will be closed. 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 87 Meeting in Rome during the IPv6 Working Group session. On behalf of the IPv6 WG co-chairs, Ray RIPE IPv6 Working Group co-Chair To the co Chairs: ipv6-wg-chair(a)ripe.net<mailto:ipv6-wg-chair@ripe.net> To the mailing list: ipv6-wg(a)ripe.net<mailto:ipv6-wg@ripe.net> For Internal Use Only

2 2

IPv6 mobile deployment (was: Why did the Google IPv6 statistics dropped for the, Netherlands?)
by Geert Jan de Groot 11 Oct '23

11 Oct '23

Hi, May I ask a different, but related question: While IPv6 migration on classic networks (server farms, internet-at-home connections) is ongoing (and has been ongoing for many, many years, alas), we don't seem to make any progress with mobile data networks. My phone shows test-ipv6.com 10/10 when connected to my home wifi, when I connect via my mobile provider, I only get IPv4/CGN. For me, this has been the case for quite a while, with multiple providers. "Mobile" is important for IPv6 migration. Without IPv6 accessibility from mobile networks, the IPv6 migration unfortunately is only engineering overhead because it will never lead to an actual migration. So, what is the opinion of the working group on this one? I did ask the Dutch regulator and they didn't seem to be interested at all in making the migration work. That worries me. Are things different in other countries? Examples we can point to? Geert Jan

6 5

Re: [ipv6-wg] IPv6 mobile deployment
by Willy Manga 11 Oct '23

11 Oct '23

Hi, [...] > Date: Wed, 11 Oct 2023 11:20:07 +0200 > From: Geert Jan de Groot <GeertJan.deGroot(a)xs4all.nl> >[...] > Are things different in other countries? Examples we can point to? India with Reliance JIO (AS55836 and AS64049) https://stats.labs.apnic.net/ipv6/IN?o=cXAw30x1r1 Closer to you, I might be wrong but the main mobile operators in France also enabled IPv6 for their customers... https://stats.labs.apnic.net/ipv6/FR?o=cXAw30x1r1 -- Willy Manga @ongolaboy https://ongola.blogspot.com/

1 0

Why did the Google IPv6 statistics dropped for the Netherlands?
by Marco Davids (Private) 11 Oct '23

11 Oct '23

Hello, Is there anyone in this group that would dare to speculate on the sudden drop in IPv6 adoption for my country, the Netherlands on this URL? https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-ad… The drop is best shown here: https://www.vyncke.org/ipv6status/project.php -- Marco

10 9

APRICOT 2024: Call for Presentations
by Mark Tinka 11 Oct '23

11 Oct '23

APRICOT 2024 21st February - 1st March, Bangkok, Thailand https://2024.apricot.net CALL FOR PRESENTATIONS ================= The APRICOT 2024 Programme Committee is now seeking contributions for Presentations and Tutorials for the APRICOT 2024 Conference. We are looking for presenters who would: - Offer a technical tutorial on an appropriate topic; - Participate in the technical conference sessions as a speaker; - Convene and chair panel sessions of relevant topics; - Lead informal Birds of Feather break out sessions. Please submit on-line at: https://papers.apricot.net/user/login.php?event=186 CONFERENCE MILESTONES ---------------------------------- Call for Papers Opens: Now Outline Programme Published: As Papers Confirmed Final Deadline for Submissions: 29th January 2024 Final Program Published: 5th February 2024 Final Slides Received: 19th February 2024 *SLOTS ARE FILLED ON A FIRST COME, FIRST SERVED BASIS, REGARDLESS OF PUBLISHED DEADLINES* PROGRAMME CONTENT ----------------------------- The APRICOT Conference Programme consists of three parts, these being Tutorials, the Peering Forum, and Conference Sessions. Topics proposed must be relevant to Internet Operations and Technologies, for example: - IPv4 / IPv6 Routing and Operations - Routing Security, including RPKI and MANRS - Internet backbone operations - Peering, Interconnects and IXPs - Content Distribution Network technology & operations - Research on Internet Operations and Deployment - Network Virtualisation - Network Automation/Programming - Network Infrastructure security - IPv6 deployment on fixed and Wireless/Cellular networks - DNS / DNSSEC and KINDNS - Access and Transport Technologies - Technical application of Web 3.0, public blockchains and cryptocurrency - Content & Service Delivery and "Cloud Computing" - 400G ZR, ZR+ & Open ROADM - Submarine cables - ChatGPT CfP SUBMISSION --------------------- Draft slides for both tutorials and conference sessions MUST be provided with CfP submissions otherwise the submission will be rejected immediately. For work in progress, the most current information available at the time of submission is acceptable. All draft and complete slides must be submitted in PDF format only. Slides must be of original work, with all company confidential marks removed. Any marketing, sales and vendor proprietary content in a presentation is against the spirit of APRICOT and it is strictly prohibited. Note that proper credit must be given for all content taken from other sources. Evidence of plagiarism is grounds for rejection. Final slides are to be provided by the specified deadline for publication on the APRICOT website. Prospective presenters should note that the majority of speaking slots will be filled well before the final submission deadline. The PC may, at their discretion, retain a limited number of slots up to the final submission deadline for presentations that are exceptionally timely, important, or of critical operational importance. Every year we turn away submissions, due to filling up all available programme slots before the deadline. Presenters should endeavour to get material to the PC sooner rather than later. Any questions or concerns should be addressed to the Programme Committee Chairs by e-mail at: pc-chairs at apricot.net We look forward to receiving your presentation proposals. Mark Tinka, Achie Atienza & Mark Duffell APRICOT 2024 Programme Committee Chairs --

1 0

IPv6 Working group call for presentations for RIPE87
by Raymond Jetten 10 Oct '23

10 Oct '23

Hello All, RIPE 87 will be held in Rome, Italy from 27 November - 1 December 2023, as well as online. For any participation form you can register here https://ripe87.ripe.net/attend/register/ The IPv6 Working Group session is scheduled for Thursday 30 November from 11:00 . 12:30 (UTC+1) 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 closer to the meeting Hope to see many of you, On behalf of the IPv6-WG Benedikt, Jen, Ray

2 2

APRICOT 2024: Call for Programme Committee Volunteers
by Mark Tinka 07 Oct '23

07 Oct '23

Hi everyone. The APRICOT 2024 Organising Committee would like to welcome everyone to join us in Bangkok, Thailand, from 21st February to 1st March 2024. The APRICOT 2024 Programme Committee is responsible for the solicitation and selection of suitable presentation and tutorial content for the APRICOT 2024 conference (https://2024.apricot.net/). We are now seeking nominations from the community to join the APRICOT 2024 PC to assist with the development of the programme for APRICOT 2024. Eligible PC candidates must have attended recent APRICOT events, 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 actively to solicit content and review submissions for technical merit. The PC meets by conference call, weekly in frequency during the three months prior to APRICOT. 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:00 UTC+8 on Friday 20th October 2023, and will announce the new PC shortly thereafter. Many thanks! Mark Tinka & Mark Duffell For the APRICOT 2024 Organising Committee --

1 0

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 03 Jun '23

03 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 17 Jan '23

17 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

APNIC IPv6 alias?
by Vasilenko Eduard 18 Oct '22

18 Oct '22

Hi all, Does APNIC has similar alias? (related to IPv6). Thanks. Ed/

1 0

web services to ipv6
by Gery Escalier 14 Oct '22

14 Oct '22

Hello everyone on the list! this is my first post, sorry if this is not the right place for my question. I currently reside in Spain, which most ISPs do not assign ipv6 to end users and with a penetration of 3% *1 I think that percentage has not changed much since 2021, it only remains to say, incredible! Previously I have used Hurricane Electric *2 when I lived in Bolivia, South America only to browse ipv6 sites. I have seen the website august.tw *3 "This is a non-profit project for learning, education and research.Our goal is to support the ever-growing internet community that wants to experiment and gain hands-on experience with the real world BGP. We provide the following services. " I am interested for personal use. -Free IPv4/IPv6 BGP tunnel-Public NAT64 server available at 2602:fc23:18::7-Public Teredo server available at teredo.august.tw Is this website known by the community?Or have any of the community users used these services?These services can be recommended for personal use? Data, I was struck by the logo shown at the bottom with a link to RIPE NCC and ARIN. I appreciate any help in this regard, thank you very much, best regards! *1 https://labs.ripe.net/documents/176/Mediterranean_country_report_Spanish_fi… *2 https://tunnelbroker.net/*3 https://august.tw/ Gery

2 1

WG co-chair selection RIPE 85
by Raymond Jetten 19 Sep '22

19 Sep '22

Dear members of the IPv6 WG list. According to our WG webpages https://www.ripe.net/participate/ripe/wg/active-wg/ipv6 it is my turn to step down as a co-chair. In a little over a month at the RIPE 85 meeting the selection will take place during the IPv6 WG session. Here is the official process: https://www.ripe.net/participate/ripe/wg/active-wg/ipv6/ipv6-wg-chair-selec… As part of the process this is a call for candidates, however I am more than happy to continue, and step up for the next term. I will open the call as from now, and the call will be closed on 30.9.2022 at 12:00 CET (Amsterdam time). If you have any questions, we , the co-chairs, will be very happy to answer them, either on the list ipv6-wg(a)ripe.net<mailto:ipv6-wg@ripe.net> or directly to us ipv6-wg-chair(a)ripe.net<mailto:ipv6-wg-chair@ripe.net>. Rgds, Raymond Jetten Raymond Jetten Senior Technology Specialist Production Cloud Services, Networks and connectivity Interconnectivity & Content Elisa Oyj Vuolteenkatu 2 33100 Tampere +358 45 6700 139 raymond.jetten(a)elisa.fi<mailto:raymond.jetten@elisa.fi> www.elisa.fi<http://www.elisa.fi/> Lisätietoa henkilötietojen käsittelystä ja tietosuojasta Elisalla https://elisa.fi/tietosuoja Mer information om Elisas hantering av personuppgifter och dataskydd https://elisa.fi/tietosuoja More information on personal data management and data protection at Elisa https://elisa.com/dataprotection ********************************************************************************************* For Internal Use Only

1 0

Mitigating the effects of SLAAC renumbering events (draft-ietf-6man-slaac-renum)
by Fernando Gont 31 Aug '22

31 Aug '22

Folks, We have been discussing the potential problems associated with SLAAC renumbering events for a while now -- one of the most common cases being ISPs rotating home prefixes, and your devices ending up with stale/invalid addresses. We have done quite a bit of work already: * Problem statement: https://datatracker.ietf.org/doc/html/rfc8978 * CPE recommendations: https://datatracker.ietf.org/doc/html/rfc9096 But there's still some work to do to address this issue: The last remaining it is to improve SLAAC such that hosts can more gracefully deal with this renumbering events. In that light, IETF's 6man has been working on this document: https://www.ietf.org/archive/id/draft-ietf-6man-slaac-renum-04.txt And we have proposed a simple algorithm for SLAAC (an extension, if you wish) that can easily help, as follows: If you (host) receive an RA that contains options, but not all of the previously-received options/information, simply send a unicast RS to the local-router, to verify/refresh that such missing information is still valid. If the information is stale, get rid of it. I presented this algorithm at the last IETF meeting (https://youtu.be/eKEizC8xhhM?t=1308). (You may find the slides here: https://datatracker.ietf.org/meeting/114/materials/slides-114-6man-improvin…) Finally, I've sent draft text for the specification of the algorithm here: https://mailarchive.ietf.org/arch/msg/ipv6/KD_Vpqg0NmkVXOQntVTOMlWHWwA/ We would be super thankful if you could take a look at the draft text (i.e., https://mailarchive.ietf.org/arch/msg/ipv6/KD_Vpqg0NmkVXOQntVTOMlWHWwA/) and provide feedback/comments. If you can post/comment on the 6man wg mailing list (https://www.ietf.org/mailman/listinfo/ipv6), that´d be fabulous. But we'll appreciate your feedback off-line, on this list, etc. (that'd still be great ;-) ) Thanks in advance! 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