- ipv6-wg - mailman.ripe.net

RIPE554-Bis consensus
by Jetten Raymond 03 Dec '21

03 Dec '21

Dear List members, The time has come, to declare consensus on RIPE554-Bis https://docs.google.com/document/d/10HsfHDOIhUPIvGk9WP0azJiIsMVzQ49RsqWfnbN… Big thanks to all list discussion participants, participants at the RIPE83 IPv6 Working Group session for their input, and most of all to Merike Käo, Jan Žorž, Sander Steffann, Tim Chown, Tim Winters for doing a lot of work. I will contact the RIPE NCC shortly to get this new document published. 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

RIPE 554 Bis to consensus...
by Jetten Raymond 03 Dec '21

03 Dec '21

Hello IPv6 Working Group! Thanks for the great discussions on the IPv6 WG during RIPE83. We are ready to get consensus on the new RIPE554 document, so here is your very very last chance to make changes by commenting it on this list. If no dramatic changes have come up we will approve the document on Friday 3.12 Link to the live draft: https://docs.google.com/document/d/10HsfHDOIhUPIvGk9WP0azJiIsMVzQ49RsqWfnbN… Cheers, The Ripe IPv6 WG chairs, Jen, Benedikt, Raymond 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

2 2

RIPE NCC Open House: Building Your Own Test Labs. Wednesday, 8 December - 1100-1230UTC
by openhouse＠ripe.net 02 Dec '21

02 Dec '21

Dear colleagues, Are you interested in deploying IPv6, but need to learn more about how it works? Do you want to try out a technology before putting it into production? Maybe you need to just test something out? Then join us at our upcoming event RIPE NCC Open House: Building Your Own Test Labs, taking place on Wednesday, 8 December. Read more about the Open House event here: https://www.ripe.net/participate/meetings/open-house/ripe-ncc-open-house-bu… <https://www.ripe.net/participate/meetings/open-house/ripe-ncc-open-house-bu…> We will talk to two experts - Ondrej Caletka and Max Stucchi - about the different choices you should make when you want to build your own test labs. Should you use hardware or virtual machines? Which software is best for a certain purpose? Do you want to run your labs in the cloud? The experts will look at different labs they developed and analyse their choices. We will of course open the mic for your questions. You can ask questions on topics like: • Why was a certain solution used? • How much time does it take to develop? • What security issues should you be aware of Take this opportunity to learn more about building test labs and share your experiences as well. Register at: https://meeting-registration.ripe.net/meeting-pub/registration?0&meetingId=… <https://meeting-registration.ripe.net/meeting-pub/registration?0&meetingId=…> I look forward to seeing you online. Alastair Strachan RIPE NCC

1 0

Re: [ipv6-wg] Latest draft for RIPE554-bis
by Eric Vyncke (evyncke) 26 Nov '21

26 Nov '21

Tim*2, Sander, Jan, and Merike, First of all, thank you for taking the pen to update this document. As you kindly asked for comments, here are some - page 2: 'fairly recent' won't age well ;-) - page 4: all requirements are limited to performance, but should it also include telemetry/monitoring ? Or is it implicit in the list of RFC ? - page 4: what about systems to handle VMs and containers ? - page 4: mobile devices have a *big difference* with normal host though as they often have multiple interfaces active at the same time. - page 4: should we assume that Wi-Fi access points are 'normal layer-2 switches' ? - page 6: I am surprised to see RFC 8415 DHCPv6 client as mandatory... - page 6: if not mistaken RFC 8200 now includes RFC 5722 and RFC 8021 (so no need to add the latter in the requirements) - page 7: same surprise to see all DHCP-related requirements - page 7 and other: nice to list some MIB but I would expect some YANG modules as well for enterprise/ISP devices - page 9: should Jen's RFC 9131 be added as optional ? Hope this helps -éric PS: the attached PDF has the same comments in the text. On 02/11/2021, 16:05, "ipv6-wg on behalf of Tim Chown via ipv6-wg" <ipv6-wg-bounces(a)ripe.net on behalf of ipv6-wg(a)ripe.net> wrote: Hi, Attached below is the latest draft for RIPE554-bis, the update to Requirements For IPv6 in ICT Equipment. The authors have incorporated feedback received on and off list, and believe the current draft is a candidate to be considered towards publication. We have a slot in the upcoming RIPE meeting to present and discuss the latest changes, but further list feedback would be welcome now. Is it ready to ship? If not, why not? The original version can be found at https://www.ripe.net/publications/docs/ripe-554 Best wishes, Tim

7 27

Latest draft for RIPE554-bis confusion with MUST and SHOULD
by Lorenz Nickel 25 Nov '21

25 Nov '21

Hey everyone, I am a bit confused/worried about section 5 (Requirements for IPv6 support in software). There is a list, of what a developer/vendor MUST (at a minimum) support. However, the list contains multiple bullet points that include words that make them seem optional (like "something SHOULD be supported" or "it's recommended"). I don't have any experience with the creation of RFC and just joined this mailing list to be able to see what you are doing here out of interest, so I think this might be (at least partly) intended, as some of these bullet points seem to have been copied from other sources (e.g., https://www.ripe.net/publications/docs/ripe-554 contains this first bullet point with "recommended"). However, I think the standard should make sense on its own and therefore don't think that this is a valid justification. Things should be clearly marked as either mandatory or optional. Therefore, I would suggest rephrasing the introduction sentence from Software developer/vendor must at a minimum do the following things to guarantee this: to [A] software developer/vendor should at a minimum do the following things to guarantee this: However, in case some things in the list should be mandatory and some optional, I think it might make even more sense to split the list in an optional and a mandatory list. If all the things in the list are actually mandatory, I would propose the following changes to the bullet points: From It is strongly recommended not to use any address literals in software code, as described in “Default Address Selection for Internet Protocol version 6” [RFC6724] to Address literals must not be used in software code, as described in “Default Address Selection for Internet Protocol version 6” [RFC6724] From Every place where IPv6 addresses are shown or output the notation as specified in "A Recommendation for IPv6 Address Text Representation [RFC5952]" should be followed to Every place where IPv6 addresses are shown or output[,] the notation as specified in "A Recommendation for IPv6 Address Text Representation [RFC5952]" must be followed From When setting up a connection the software should follow Default Address Selection for Internet Protocol Version 6 [RFC6724] or Happy Eyeballs Version 2: Better Connectivity Using Concurrency [RFC8305] to When setting up a connection[,] the software must follow Default Address Selection for Internet Protocol Version 6 [RFC6724] or Happy Eyeballs Version 2: Better Connectivity Using Concurrency [RFC8305] From These requirements should also be checked in any library or tools used by the software to These requirements must also be checked in any library or tools used by the software I'm not particular interested in what wording exactly is used, these are just some suggestions. Please feel free to let me know what you think. Lorenz

1 0

Re: [ipv6-wg] Latest draft for RIPE554-bis
by Jetten Raymond 03 Nov '21

03 Nov '21

Hi, First of all thanks to all who participated in the update of this document ! Its only a few weeks before the RIPE 83 virtual meeting, so I hope most of the discussion will be here on the list before the meeting. During RIPE 83 we have only a 45 minute slot altogether so we don't have unlimited time there to discuss these. I hope we have enough consensus to have this published during the meeting, so please show your support, or ask, comment etc already now. Rgds, Ray IPv6 wg co chair -----Original Message----- From: ipv6-wg <ipv6-wg-bounces(a)ripe.net> On Behalf Of Tim Chown via ipv6-wg Sent: tiistai 2. marraskuuta 2021 17.05 To: ipv6-wg(a)ripe.net Cc: Sander Steffann <sander(a)steffann.nl>; Jan Zorz - Go6 <jan(a)go6.si>; Merike Kaeo <merike(a)doubleshotsecurity.com> Subject: [ipv6-wg] Latest draft for RIPE554-bis Hi, Attached below is the latest draft for RIPE554-bis, the update to Requirements For IPv6 in ICT Equipment. The authors have incorporated feedback received on and off list, and believe the current draft is a candidate to be considered towards publication. We have a slot in the upcoming RIPE meeting to present and discuss the latest changes, but further list feedback would be welcome now. Is it ready to ship? If not, why not? The original version can be found at https://www.ripe.net/publications/docs/ripe-554 Best wishes, Tim

2 1

Latest draft for RIPE554-bis
by Tim Chown 02 Nov '21

02 Nov '21

Hi, Attached below is the latest draft for RIPE554-bis, the update to Requirements For IPv6 in ICT Equipment. The authors have incorporated feedback received on and off list, and believe the current draft is a candidate to be considered towards publication. We have a slot in the upcoming RIPE meeting to present and discuss the latest changes, but further list feedback would be welcome now. Is it ready to ship? If not, why not? The original version can be found at https://www.ripe.net/publications/docs/ripe-554 Best wishes, Tim

1 0

broken-v6only
by Jens Link 25 Oct '21

25 Oct '21

Hi, just ran into this on twitter: https://github.com/buraglio/broken-v6only --- A running list of applications and processes that just do not work with the total absence of IPv4 on on a host. Contributions welcome and encouraged. --- Maybe the RIPE community can give more input. Jens -- ---------------------------------------------------------------------------- | Delbrueckstr. 41 | 12051 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink(a)quux.de | --------------- | ----------------------------------------------------------------------------

2 1

Call for presentations for RIPE 83
by Jetten Raymond 25 Oct '21

25 Oct '21

For Internal Use Only Hello All, Unfortunately RIPE83 will yet be virtual, from 22 - 26 November 2021 The IPv6 Working Group session is scheduled for , Thursday 25 November from 13.00 - 13:45 (UTC+1) We are looking for talks - please email : ipv6-wg-chair (at) ripe.net if you'd like to present. Once we have decided on the agenda, we'll contact the presenters. Thanks! Jen, Benedikt, Ray

1 0

New on RIPE Labs: Hands-On Learning - How We Built the IPv6 Security Virtual Lab Activities
by Ulka Athale 18 Oct '21

18 Oct '21

Dear colleagues, Our newest course in the RIPE NCC Academy - IPv6 Security - has a virtual lab environment so that you can get hands-on practice in addition to learning about theoretical concepts. Ondrej Caletka shares how this virtual lab was built in this RIPE Labs article: https://labs.ripe.net/author/ondrej_caletka_1/hands-on-learning-how-we-buil… You are also invited to participate in the 'RIPE NCC Open House: Become a Certified Professional in IPv6 Security’ virtual event taking place on Wednesday, 20 October. You can hear from the team behind the IPv6 Security e-learning course and RIPE NCC Certified Professionals exam about how the course and exam were created. This is an opportunity to ask any questions you might have about the IPv6 Security Expert exam and course. Register for the event at: https://www.ripe.net/participate/meetings/open-house/ripe-ncc-open-house-be… Kind regards, Ulka Athale Senior Communications Officer, RIPE NCC

1 0

Fwd: [v6ops] RFC 9098 on Operational Implications of IPv6 Packets with Extension Headers
by Fernando Gont 16 Sep '21

16 Sep '21

Folks, FYI: RFC 9098 Title: Operational Implications of IPv6 Packets with Extension Headers Authors: F. Gont, N. Hilliard, G. Doering, W. Kumari, G. Huston, W. Liu Available at: https://www.rfc-editor.org/info/rfc9098 Consider this one a companion document of RFC7872. Thanks! Regards, Fernando -------- Forwarded Message -------- Subject: [v6ops] RFC 9098 on Operational Implications of IPv6 Packets with Extension Headers Date: Wed, 15 Sep 2021 12:23:19 -0700 (PDT) From: rfc-editor(a)rfc-editor.org To: ietf-announce(a)ietf.org, rfc-dist(a)rfc-editor.org CC: drafts-update-ref(a)iana.org, v6ops(a)ietf.org, rfc-editor(a)rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 9098 Title: Operational Implications of IPv6 Packets with Extension Headers Author: F. Gont, N. Hilliard, G. Doering, W. Kumari, G. Huston, W. Liu Status: Informational Stream: IETF Date: September 2021 Mailbox: fgont(a)si6networks.com, nick(a)inex.ie, gert(a)space.net, warren(a)kumari.net, gih(a)apnic.net, liushucheng(a)huawei.com Pages: 17 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-ipv6-ehs-packet-drops-08.txt URL: https://www.rfc-editor.org/info/rfc9098 DOI: 10.17487/RFC9098 This document summarizes the operational implications of IPv6 extension headers specified in the IPv6 protocol specification (RFC 8200) and attempts to analyze reasons why packets with IPv6 extension headers are often dropped in the public Internet. This document is a product of the IPv6 Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor(a)rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ v6ops mailing list v6ops(a)ietf.org https://www.ietf.org/mailman/listinfo/v6ops . “This communication is the property of EdgeUno or one of its group companies and/or affiliates. This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and if you are not the intended recipient be aware that any non-explicitly authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, and will be considered a criminal offense. Please notify legal(a)edgeuno.com about the unintended receipt of this electronic message and delete it.”

1 0

[news] Announcing the IPv6 Security Expert Exam and E-Learning Course
by Sandra Bras 15 Sep '21

15 Sep '21

Dear colleagues, Our second IPv6 exam certification - IPv6 Security Expert is now live. We have also launched a new e-learning course on IPv6 Security in the RIPE NCC Academy that is aligned with the exam. With the uptake in IPv6 adoption, we hope to see more network operators taking the necessary security precautions when using IPv6 and following best practice. The course consists of 17 modules and 7 lab activities, which will help you apply concepts learned and using actual tools and realistic scenarios. You can find out more about the IPv6 Security Expert certification here: https://www.ripe.net/support/certified-professionals/ipv6-security-expert-e… <https://www.ripe.net/support/certified-professionals/ipv6-security-expert-e…> And take a look at the IPv6 Security online course in the RIPE NCC Academy at: https://academy.ripe.net <https://academy.ripe.net/> I would like to acknowledge everyone who has participated in the exam and course creation process, from answering our job task analysis survey to testing the exam and reviewing the course material to testing the lab activities. Having the involvement of the community is one of the strengths of our exams, and we thank all our volunteers. If you have any questions or feedback, you can reach us at <exams(a)ripe.net <mailto:exams@ripe.net>>. Best regards, Sandra Bras Assistant Manager Learning and Development RIPE NCC

1 0

RIPE-554-bis
by Azael Fernandez A. 08 Sep '21

08 Sep '21

Hi, I have been following the presentation in May and the messages in this list, and since 2018 I have asked *Jan *if you were planning to update this document. So I am very delighted to see that it is happening. By reviewing the new version I would suggest, in the case of the RFCs that are in the category of Standards Track, to have the indication of Standard, for example when updating the IPv6 Basic specification it would be better to write it in the following way: IPv6 Basic specification [RFC8200 or STD 86] and better to also have the reference to the RFC made obsolete by standard tracks for example, in this case: IPv6 Basic specification [RFC8200 or STD 86] (made obsolete RFC 2460), the main reason is that in almost all the datasheets, the original or previous RFC are still mentioned. Finally, I found a writing error in the mandatory support for CPE equipment, it says RFC7094, and it should be RFC*7084.* BEST, Azael

2 1

New on RIPE Labs: Managing DNS Over IPv6 Only
by Alun Davies 02 Sep '21

02 Sep '21

Dear colleagues, Paul de Weerd and Florian Obser share a short use case looking at why and how the team recently switched the management interfaces for the RIPE NCC DNS servers over to IPv6 only. Read more on RIPE Labs: https://labs.ripe.net/author/paul_de_weerd/managing-dns-over-ipv6-only/ Kind regards, Alun Davies RIPE Labs Editor RIPE NCC

1 0

New on RIPE Labs: IPv6 Support on the PlayStation 5
by Alun Davies 30 Aug '21

30 Aug '21

Dear colleagues, In a new guest post on RIPE Labs, Tore Anderson takes a look at how IPv6 capability has come on with the arrival of the next generation of gaming consoles: https://labs.ripe.net/author/toreanderson/ipv6-support-on-the-playstation-5/ Kind regards, Alun Davies RIPE Labs Editor RIPE NCC

1 0

RIPE 82 IPv6 WG minutes published
by Jetten Raymond 15 Jun '21

15 Jun '21

Dear list members, The minutes from the RIPE 82 IPv6 Wg session have now been published. https://www.ripe.net/participate/ripe/wg/active-wg/ipv6/minutes/ipv6-workin… Rgds, your IPv6 wg co-chairs, Jen, Benedikt and Ray

1 0

WebinarIPv6 Mythology
by Maysa de Freitas Souza 08 Jun '21

08 Jun '21

Hi all, IPv6 Mythology webinar will happen on 09/06 at 4pm ART (UTC-0300). Linkedin event link: https://www.linkedin.com/events/edgeunowebinar-ipv6mythology680338496503682… Thanks and Best Regards

1 0

New on RIPE Labs: Two Articles on IPv6
by Alun Davies 04 Jun '21

04 Jun '21

Dear colleagues, Ahead of 6 June, we’ve published two RIPE Labs articles covering two important topics in IPv6. Looking into IPv6 adoption in 2021, Stephen Strowes and colleagues examine the difference between average IPv6 capability per country over a few days in June 2020 versus the most recent similar averages for 2021: https://labs.ripe.net/author/stephen_strowes/ipv6-adoption-in-2021/ And on the topic of IPv6 security, Alvaro Vives looks at the security challenges that come with IPv6 and talks about how our IPv6 security course helps people and organisations get prepared to keep the future Internet secure: https://labs.ripe.net/author/alvaro_vives/securing-the-future-of-ipv6/ Kind regards, Alun Davies RIPE Labs Editor RIPE NCC

1 0

RIPE82 IPv6 Working group session Minutes
by Jetten Raymond 04 Jun '21

04 Jun '21

Dear members of the IPv6 Working Group, Below are the draft minutes from the RIPE 82 virtual meeting, Thanks to the RIPE NCC for these, If you have any comments or remarks please let us know before 10.6.2021 IPv6 Working Group Minutes - RIPE 82 Thursday, 20 May 10:30 - 12:00 (UTC+2) WG Chairs: Benedikt Stockebrand, Jen Linkova, Raymond Jetten Scribe: Adonis Stergiopoulos Status: Draft Welcome / Agenda The Chairs This presentation is available at:  https://ripe82.ripe.net/wp-content/uploads/presentations/39-_RIPE82_IPv6WG_… The minutes from RIPE 81 were approved. There were no questions or comments. WG Chair Re-selection The Chairs Jen Linkova was selected for another three years as co-chair of the working group. An Update on Fragmentation Loss Rates in IPv6 Geoff Huston This presentation is available at: https://ripe82.ripe.net/wp-content/uploads/presentations/17-huston-ipv6-v6f… Lars Prehn (MPII) asked how many vantage points his team measured from, and if it was really the end hosts that failed, or if there might just be few misconfigured “choke” routers close to the vantage point through which most traffic for the American-based devices passed. If that was the case, the numbers might just reflect the fraction of devices routed via those routers. Geoff said they used four server points and, looking closer at Canada and the USA, different networks had different loss rates, so it was far more likely that this was close to the edge, not close to them. They also measured entire continents, hence they were finding that the “choke” points were not close to them and it was more likely that they were closer to the user, or in the network at that last-hop access network. Richard Patterson (Sky) asked if the tests included atomic fragments. Jen clarified that during the presentation, Geoff mentioned that his team used two fragments, initially a larger one and then a smaller one, so it was just one packet with a fragment header but no subsequent fragment. Geoff said this was coming up. In about a month's time, they would have some data available. Ivan Beveridge (Independent) asked about fragmentation and if they considered that some firewalls set MSS around 1,380. If that was tunnelled, for example due to DDoS-mitigation, they might see some issues. Geoff said yes, but some seemed to go at 1,400. If a firewall set an MSS down that low, this could create issues and it would be a bizarre thing to do. David Schweizer (NetDEF) asked if they had done any tests with fragment sizes less than 1,200. Geoff said 1,200 was the smallest size they had used. Oliver Gasser (Max Planck Institute for Informatics) asked what the baseline drop rate for IPv6 was. Geoff said this was a talk for another time, but from what he remembered, the base rate was 2%. Christian Bretterhofer (Independent) asked for an example configuration for ISPs and enterprises to show how to make this work. Geoff said it was simple - they should not drop fragments and ask their router vendors not to drop packets with extension headers. Jan Žorž (6connect) asked what people inside their particular countries coud do to make this better and how to approach this issue. Geoff said he didn’t know, since equipment had changed and improved over the last five years. Alex Le Heux (Independent) asked if they would publish this data with per-AS granularity. Geoff said yes, and they could be found on the link in the presentation. Marek Barczyk (SUT Computer Center) asked if they considered testing drop rate of fragmented vs packets with other IPv6 options that triggered a slow path. Geoff responded that he had not considered extension header options other than a null fragment, but he would be willing to test any if people wanted to use them on the network. RIPE554-bis Tim Chown The presentation is available at: https://ripe82.ripe.net/wp-content/uploads/presentations/66-ripe82-ipv6wg-r… Jordi Palet Martinez (Independent) referred to slide three of the presentation and asked why only MAP/DS-Lite and not 464XLAT and lw4o6 were used. He volunteered to contribute to this or any other parts of the document. Tim said that Jordi had contributed a lot on this particular topic in the IETF. He thought 464XLAT would be in there but he was unsure about a lightweight lw4o6. He asked Jodie to post this on the list, as it would be mentioned along with NAT64 and DNS64. Jan Žorž (6connect) said this was just the current version of the document. They wanted to publish it as soon as possible, since many people were using it. If anyone wanted to add additional sections, they were happy to update it after the current version had been published. MAP-E Residential Deployment and the Issues Encountered Yannis Nikolopoulos This presentation is available at: https://ripe82.ripe.net/wp-content/uploads/presentations/78-ripe82-yanodd-m… Blake Willis (Zayo Europe) asked what the driver was that pushed them to switch from MAP-T to MAP-E and if this was attributed to services module requirements. Yannis said they had only ever tried MAP-T in a very brief trial six years ago, and they did not really switch from MAP-T to MAP-E. After they tested both in the trials, they decided to go ahead with MAP-E. Jan Žorž (6connect) asked what the top three operational issues were with lw4o6 that put them off this path. Yannis said the CPE and the AFTR, as the AFTR could not scale well to a large number of subscribers. Also, the vendor could not put up the extra development effort because there was no interest from other operators. He could not recall a third issue at that moment. Richard Patterson (Sky) asked for more information on the issues with anycasting the BR and the limitations with policy-based routing that required the ASR99 to be dedicated. Yannis said a potential issue was that an ICMP IPv6 packet that was too big might be sent to the wrong BR if it was anycasted. About the policy-based routing, since MAP-E was implemented as a routing mechanism in Cisco, they put a limit to a specific number of PBR that can be implemented on the box. The limitation was that it can be either one or two per direction. Jordi Palet Martinez (Independent) referred to slide 24 of the presentation where Yannis talked about S46 RFC8026. He thought it was much better to use RFC 8585, which also included support for 464XLAT. He had much more success in several broadband deployments (GPON, DSL, cellular broadband and just cellular) than all the other options. He said he was also now working on a deployment for 25 million subscribers. Yannis thanked Jordi for the suggestions. Sia Saatpoor (Logius) asked about the activation of IPv6 and the use of stimulation. He thought the major role and responsibility for the use of IPv6 lay with the government. In the Netherlands, the highest ICT policy body of the government had decided that all digital Dutch governments must be accessible through IPv6 by the end of 2021. Sia asked what was the role of the government in Greece or other parts of Europe in stimulating the industry. Yannis said he could only talk about the Greek government. It was currently not too far behind, but operators were running part of the governmental network, so they were trying to push IPv6 as much as they could. He was not aware of a Greek government-specific initiative at this point. Kostas Zorbadelos (Independent) asked if software mechanisms were the way forward, or if should they stick to CGN (for the IPv4 path) in dual-stack deployments. Yannis replied that he really hoped software mechanisms were still the way to go. IPv6 Deployment Status Paolo Volpato This presentation is available at: https://ripe82.ripe.net/wp-content/uploads/presentations/64-RIPE-82-Fioccol… Christian Bretterhofer (Andritz AG) said that many people did not find any business reason to adopt IPv6. He asked if there were any reasons to adopt IPv6. Paolo answered that this was one of the most interesting and critical questions. Unfortunately, there was no definitive answer, and this was also part of the discussion. He advised Christian to look at the use cases and spend more time reading through their draft. Some operators had moved to IPv6 for innovation reasons, enabling new applications even if they were not here yet. There was also some kind of consensus that 5G and IoT were two cases demanding IPv6, but that was not entirely true. Another motivation, which was still somewhat unclear, was the role of governments and national authorities’ actions in favour of IPv6 deployment. He added that there were cases, two of them were in the USA and China, where federal and government agencies had demanded not just support for IPv6, but potentially having only IPv6-based applications. Veronika McKillop (UK IPv6 Council) said that the introduction of IPv6 did not immediately relieve the pressure on the IPv4 address pool, and dual-stack did not help with this problem. Only IPv6-only deployment helped with the IPv4 address shortage. She noted that it would be worth clarifying this on the relevant slide. Paolo agreed and said he would update the materials. Happy Eyeballs Considered Harmful Jens Link The presentation is available at: https://ripe82.ripe.net/wp-content/uploads/presentations/80-he.pdf Jordi Palet Martinez (Independent) said that he had described this problem a long time ago and it was the reason he had proposed it in the IETF (“Reporting of Happy Eyeballs v2 Failures<https://www.ietf.org/archive/id/draft-palet-ietf-v6ops-he-reporting-00.txt>”), so that ISPs knew something was broken. Jens agreed and replied that other people saw the same problem. Blake Willis (Zayo Europe) asked if the community was aware of a tool, site or application that users could use to catalog IPv6 problems. Or was that ecosystem hopelessly fragmented too? His question was not answered. Christian Bretterhofer (Andritz AG) asked if there was a browser plugin to show Happy Eyeball problems like IPvFoo. Jens replied that he was not aware of a plugin and he suggested talking to the browser windows. Alexander Azimov (Yandex) asked whether the adoption of NEL (Network Error Logging) was solving this kind of problem. Jens replied that it might be. He then asked if it was enabled somewhere and if it was analysed should it be enabled. Gert Doering (Independent) said another example they saw was that Apache-ACLs were not right for IPv4 and browsers were randomly flip-flopping IPv4 and IPv6, and that user reports were inconclusive. End of session. On behalf of the IPv6 WG co-chairs, Raymond For Internal Use Only

1 0

RIPE-554-bis
by christian bretterhofer 27 May '21

27 May '21

Just a question: Why are there no Firewalls? -- --- best regards Christian Bretterhofer

4 3

RIPE554-bis - on agenda Thursday
by Tim Chown 17 May '21

17 May '21

Hi, The work on updating RIPE554 will be presented on Thursday at the IPv6 WG meeting. This is the document specifying "Requirements For IPv6 in ICT Equipment” last revved in 2012. You can see the current state of the proposed new version of the doc at: https://docs.google.com/document/d/10HsfHDOIhUPIvGk9WP0azJiIsMVzQ49RsqWfnbN… and a PDF is also attached along with the current draft of Thursday’s slides. We’re largely focused on an update to the current document given the previous version is almost 10 years old and not, at this stage at least, expanding the scope. Comments to the list are welcome, be they general or on specific requirements in the text. Tim

1 0

FW: [ripe-list] Community Wellbeing Survey
by Jetten Raymond 04 May '21

04 May '21

Dear all, I had a request from Erik Bais that I'd like to forward to our list, please see below Kind regards, Ray For Internal Use Only From: On Behalf Of Erik Bais Sent: tiistai 4. toukokuuta 2021 11.14 Subject: FW: [ripe-list] Community Wellbeing Survey Dear WG-Chairs, As not everyone in the community is subscribed to the RIPE ML, I would kindly ask you if you could forward the email below on your WG ML in order to get to a larger audience. Kind regards, Erik Bais From: ripe-list on behalf of Erik Bais Date: Friday 30 April 2021 at 17:59 To: ripe-list Cc: Erik Bais Subject: [ripe-list] Community Wellbeing Survey Dear RIPE Community, A couple months ago we began discussing in a small group the challenges around personal mental wellbeing in the RIPE community and how we could potentially investigate the issue and what we could potentially put in place to make things better. One outcome of that was the development of a questionnaire around how the community is coping in the current Covid-19 era. ( The questionnaire is here: https://www.surveymonkey.com/r/JPNJG57 ) Participating in this is a personal decision for you but we do appreciate your feedback, either via the questionnaire or other means. As some of you may know, I did a presentation in 2019 at the Dutch Network Operator Group ( NLNOG ) - https://www.youtube.com/watch?v=7areInUXbyo about working in a toxic work environment and the risks of running into a burnout. This topic, ( having a burnout . .the risks and being able to talk about this in groups of small peers or even in public ) is in many countries and communities still a taboo topic. Based on the experiences that we have from that presentation and what it did for the people in the Dutch NLNOG community.. and providing a safe place for people to talk and discuss about this.. We decided that we also would like to see what the current state is in the larger community .. and start with a questionnaire on the topic. The feedback and results of the questionnaire ( and your input is highly appreciated if you participate ) will be looked at and I will do a presentation in a plenary at RIPE82 in a couple weeks. The goal is to see if we as a RIPE community need to provide similar ways for people in our region to (anonymously) be able to communicate about various topics that may or may not be directly work related. It could be that we need to have a place where we can discuss about the situation working remote .. not being able to go to the office.. the additional stress that this brings .. or that we need to talk about what all those additional social distancing rules bring to you.. or how you feel about these rules.. for some it is a blessing .. and for some it works like a new stress factor as the rules are changing per shop / public store / building .. and some of us like to have nice and clear directions .. But also about how people deal with the lockdowns .. and don't get to meet other people that have a similar interest .. or a relation .. So what we like to see is how are you feeling .. how are you coping .. or not .. And then the question comes .. can we help .. and how I'm aware that I'm currently the one that is pushing this as a topic in public (and here for instance) .. but I'm very aware of the group of great people that helped to get this initiative and questionnaire to a state as where it is today. And I would especially like to thank Eileen (INEX), Mirjam ( RIPE Chair ), Carolien (NCC HR) , Alastair ( NCC ), Ulka ( NCC ) Alun ( NCC ), Vesna ( NCC - for her mad Wiki and notary skills ) and the people assisting in reviewing the questionnaire already for us. We like to get the information before May 11th 2021, so that we have some time to look at the results and prep the ppt for the week of the RIPE82 meeting. The data itself will be stored for max 2 weeks after that.. and only 1 admin from the NCC and the HR manager of the NCC will have access to the data, besides myself. As we use the NCC survey monkey account for the questionnaire. All questions can be skipped if you don't feel like you want to answer a specific question. And feel free to reply here on the list .. or reach out to Mirjam, Eileen (both in CC: ) or myself in private if needed. We are planning a bit larger support group once we are done with the RIPE82 meeting on this. To minimize tracking by Survey Monkey .. You can paste the questionnaire URL in an incognito window.. The questionnaire is here: https://www.surveymonkey.com/r/JPNJG57 Thank you all in advance and see you all at RIPE82. Kind regards, Erik Bais

1 0

IPv6 WG chair 2021 re-selection
by Jen Linkova 22 Apr '21

22 Apr '21

Hello, My 3 years term as the IPv6 WG co-chair will be over after RIPE82, so the call for the candidates is open. I'd like to stand for re-selection as well, volunteering to serve another term. If you'd like to volunteer or nominate someone (or just make a comment ;), please send an email to the list (or respond to this thread). The closing date for candidates will be Sunday, May 16th 2021, 23:59:59 UTC. The WG chair selection will happen during the IPv6 WG session @ RIPE82 (currently scheduled for May 20th, 10:30am CEST time zone (UTC+2) Thank you! -- SY, Jen Linkova aka Furry

7 6

RIPE82 (virtual) IPv6 working group
by Jetten Raymond 08 Mar '21

08 Mar '21

Dear IPv6 wg list members, I am pleased to tell you that we at this moment already have a full agenda for the IPv6 wg session. Thanks to all of you who have suggested presentations to us. if you have plans to yet send in presentations you will be put on a "spareparts" list if a cancellation occurs, or we may have you at a next meeting. we will publish the agenda in the coming weeks. Thanks from all of us Jen, Benedikt and Ray

1 0

New on RIPE Labs: The State of IPv6 Support on the Tor Network
by Alun Davies 05 Mar '21

05 Mar '21

Dear colleagues, The team behind the Tor Project has been making good on its goal to provide improved IPv6 support on the Tor network. For more information, read the latest update on RIPE Labs: https://labs.ripe.net/Members/tor_grants/the-state-of-ipv6-support-on-the-t… Kind regards, Alun Davies RIPE Labs Editor RIPE NCC

1 0