- ipv6-wg - mailman.ripe.net

Fwd: RFC 9288 on Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers
by Fernando Gont 19 Aug '22

19 Aug '22

Hi, FYI. RFC 9288, "Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers" (available at: https://www.rfc-editor.org/rfc/rfc9288) FWIW, IMO most of the value is in the analysis of what protocols/features use what EHs, and what would break (if anything) if packets with EHs are dropped. These other two are useful for context: * RFC 9098, "Operational Implications of IPv6 Packets with Extension Headers" (https://www.rfc-editor.org/rfc/rfc9098.html) * RFC 7872, "Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World (https://www.rfc-editor.org/rfc/rfc7872.html). Thanks! Cheers, Fernando -------- Forwarded Message -------- Subject: RFC 9288 on Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers Date: Thu, 18 Aug 2022 16:21:47 -0700 (PDT) From: rfc-editor(a)rfc-editor.org To: ietf-announce(a)ietf.org, rfc-dist(a)rfc-editor.org CC: rfc-editor(a)rfc-editor.org, drafts-update-ref(a)iana.org, opsec(a)ietf.org A new Request for Comments is now available in online RFC libraries. RFC 9288 Title: Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers Author: F. Gont, W. Liu Status: Informational Stream: IETF Date: August 2022 Mailbox: fgont(a)si6networks.com, liushucheng(a)huawei.com Pages: 33 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-opsec-ipv6-eh-filtering-10.txt URL: https://www.rfc-editor.org/info/rfc9288 DOI: 10.17487/RFC9288 This document analyzes the security implications of IPv6 Extension Headers and associated IPv6 options. Additionally, it discusses the operational and interoperability implications of discarding packets based on the IPv6 Extension Headers and IPv6 options they contain. Finally, it provides advice on the filtering of such IPv6 packets at transit routers for traffic not directed to them, for those cases where such filtering is deemed as necessary. This document is a product of the Operational Security Capabilities for IP Network Infrastructure 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 _______________________________________________ IETF-Announce mailing list IETF-Announce(a)ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce

2 1

New on RIPE Labs: Deploying IPv6-Mostly Access Networks
by Anastasiya Pak 02 Aug '22

02 Aug '22

Dear colleagues, Dual stack is the most common way of deploying IPv6 in access networks. A recent standard defines IPv6-mostly access networks, providing IPv4 connectivity only for legacy devices while allowing modern devices to run IPv6-only. My colleague Ondřej Caletka explored the deployment of IPv6-Mostly Access Networks. Read his article on RIPE Labs: https://labs.ripe.net/author/ondrej_caletka_1/deploying-ipv6-mostly-access-… Best regards, Anastasiya Pak Marketing & Communications Officer RIPE NCC

1 0

Call for presentations IPv6 WG @RIPE85
by Jetten Raymond 25 Jul '22

25 Jul '22

Hello All, RIPE 85 will take place from 24-28 Oktober 2022 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 Belgrade Serbia. For both cases you can register here: https://ripe85.ripe.net/attend/register/ The IPv6 Working Group session is scheduled for Wednesday 26 Oktober from 12:00 . 13:00 (UTC+1) We still have some time in our session. 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 0

Minutes from RIPE84 IPv6 WG
by Jetten Raymond 25 Jul '22

25 Jul '22

Dear IPv6 WG list members, Here are the minutes from the IPv6 WG session from RIPE 84 in Berlin and online. A very big thank you to Gerardo and Ulka from the RIPE NCC. If you have any comments or remarks please let us know as soon as possible. We plan to publish the minutes at latest 2 weeks from now. Thanks, The IPv6 co-chairs IPv6 Working Group Minutes Date: Thursday, 19 May 11:00 - 12:30 (UTC+2) Chaired By: Benedikt Stockebrand, Jen Linkova, Raymond Jetten Scribe: Gerardo Viviers Welcome, Etiquette, Approving Minutes Working Group Co-Chairs Raymond Jetten, Working Group Co-Chair, welcomed everyone to the session and went over some rules of engagement. There were no questions or comments. IPv6 and the Windows 10 Firewall Wilhelm Boeddinghaus, system.de This presentation is available here: https://ripe84.ripe.net/wp-content/uploads/presentations/100-Boeddinghaus-R… Wilhelm did an in-depth analysis of how IPv6 is handled by the Windows 10 Defender Firewall software. The presentation conclusions provided some advice on how to best configure the firewall to provide good security for IPv6. Alvaro Vives, RIPE NCC, asked if there were improvements to the default firewall rules in Windows 11. Wilhelm said that he didn't think so, but he had not yet looked into Windows 11, and that he didn't expect the rules to be any better and maybe they should be proposed by the community. Christian Bretterhofer, Andritz AG, asked if there is a tool which allows users to see the firewall rules. Wilhelm replied that the Microsoft administration interface displays the rules. Most of the outgoing rules are not needed, because everything outgoing is allowed. He suggested that there might be some other firewall tools which were better. Kurt Kayser, Kurt Kayser Konsultation, commented that on the slides, the link local prefix was /64 and not /10. Wilhelm explained that this prefix size was mentioned in the Microsoft environments and simply took it over. Jan Zorz, 6connect, asked if Wilhelm thinks it's still a good idea to have a central firewall and not rely on the Windows 10 firewall. Wilhelm explained that you cannot rely on the Windows 10 firewall, but you must use it anyways. The central firewall does not protect your LAN. To ensure a secure environment, we need to use all the firewalls and packet filters available. Kostas Zorbadelos, CANAL+ Telecom, said that a default rule set is a problem, and asked Wilhelm if he had a suggestion for what the default ruleset should be. Wilhelm answered that it was difficult to come up with a real new default ruleset, because it is application centred. It depends on where the PC is used - in a loose environment or in a strict environment. Maybe the community can come up with a better firewall rule set. Maria Matejka, CZ.NIC, mentioned that one problem is a too-open firewall, and another is a too-closed firewall. The area of too closed and too open overlaps. We can't find a solution to having the firewall not too open and not too closed. Rule confirmations pop up frequently and home users click without thinking about it. Wilhelm replied that home users usually don't know much about packets and ports, so they don't understand what is right or wrong. Maybe the enterprise admins can make better rules for their environment, as they have the knowledge. Jen Linkova, Google, mentioned she is not a Windows user, but wondered if the firewall rules related to Neighbor Discovery might be useful for VMs on the same device. Wilhelm replied that he didn't think so. The VM packets don't need to be sent outside. Virtualisation is an enterprise feature and should be dealt with by the enterprise administrators. IPv6 Deployment Status: Update and Remaining Challenges Paolo Volpato, SID and Huawei Technologies This presentation is available here: https://ripe84.ripe.net/wp-content/uploads/presentations/114-IPv6_Status_Pa… Paolo presented on the status of IPv6 deployment around the world, pointing out how the statistics need a more refined interpretation to approach a true status. Christian Bretterhofer, Andritz AG, asked when companies in China would get access to IPv6 and open connectivity. His experience in China was difficult and the ISPs offered only a /64 IPv6 prefix. Paolo said that the plan was to have a good percentage of IPv6-only networks in China by 2030. He added that the issue of open connectivity could not be addressed in the current session. Maximilian Wilhelm, Cloudflare, commented that he felt IPv6 is a second-class citizen on Paolo's platform and asked when will IPv6 be on par with IPv4. Paolo answered that he is confident IPv6 is not a second-class citizen and if there is something to be fixed, he will pass on any messages to the headquarters for support. Jad el Cham, RIPE NCC, asked about IPv6 policies that have a good impact on IPv6 deployment. Paolo replied that certain policies in the USA have triggered some questions about IPv6 deployment. He added that his personal view was that the expectations are high and he doesn't believe that the proposed dates are realistic. Paolo suggested looking at countries like India, China, and Brazil, along with the EU. He expects that 2030 might be the flag year in which we might actually transition networks to IPv6. Maximilian Emig, aiticon GmbH, mentioned that Paolo's employer, Huawei, has been pushing the "New IP" proposal, which has received extensive press coverage. He asked Paolo to elaborate on how it fits with IPv6. Paolo mentioned he did not have an official answer. His personal opinion is it was a mistake, and it is not related to IPv6. Just Another Measurement of Extension Header Survivability (JAMES) Justin Lurman, ULiege, and Eric Vyncke, Cisco This presentation is available here: https://ripe84.ripe.net/wp-content/uploads/presentations/32-JAMES-RIPE84.pdf Justin Lurman provided an overview of how IPv6 packets using Extension Headers are processed or dropped on the public Internet. There were no questions or comments. IPv6 Addressing Inside a VPN Tunnel Between Endpoints With Rotating Prefixes Matthias Scheer, AVM This presentation is available here: https://ripe84.ripe.net/wp-content/uploads/presentations/59-ripe84_ipv6wg_v… Matthias Scheer presented on the challenges encountered by networks attempting to route IPv6 within VPNs, when the IPv6 prefixes assigned to the endpoints are rotated. Christian Betterhofer, Andritz AG, asked if there was any chance to update the Fritz 7582, specially the Wireguard support. Matthias replied that Wireguard support is available. He suggested to go to website and try out the beta, which is quite safe. Anže Jenšterle, AS211776, commented that Wireguard prefers IPv6 in DNS resolution only and this depends on how the resolver code is written. Jen Linkova, Google, mentioned that strictly speaking RFC 4193 does not recommend, it says certain addresses "CAN" be used. The language is not "SHOULD". Jen added that the default address selection is called "default" for a reason. Jan Zorz, 6connect, pointed out that Matthias mentioned the problem of rotating prefixes. Jan asked Matthias that if he came across ISPs that do this, he should point them to RIPE 690. Jan also mentioned that RFC 9096 talks about ways to improve the reaction of CPEs to IPv6 renumbering events. Gert Doering, congratulated AVM on working on IPv6 by default on their CPEs and on the work with IPv6 and VPNs. He mentioned that he liked the idea of using OSPFv3 to cope with renumbering events. Matthias remarked that he removed some slides that dealt with this topic due to time constraints. David Lamparter, OpenSourceRouting and NetDEF, replied to Jan Zorz's comment on RIPE 690 saying that he has customers that request prefix rotations. The RIPE document is not important for him. He applauded AVM's work on solving the prefix rotation problem. Matthias agreed that it was a good idea to continue the dialogue and find a solution together. Round Up and Thanks Working Group Co-Chairs The Working Group Co Chairs thanked the attendees for joining the session. For Internal Use Only

1 0

Join our Upcoming Open House on the IPv6 Skills Gap
by Alastair Strachan 14 Jun '22

14 Jun '22

Dear colleagues, We are organising an Open House on the IPv6 skills gap. The event will take place on Wednesday, 29 June from 10:00-11:30 UTC. Lack of adequate know-how remains a roadblock for IPv6 transition. Join us for a discussion on the challenges of building IPv6 skills. We'd love to hear your thoughts and suggestions! Register for free at: https://www.ripe.net/participate/forms/apply/openhouse-ipv6skills-29-june-2… <https://www.ripe.net/participate/forms/apply/openhouse-ipv6skills-29-june-2…> I hope to see many of you at there! Best regards, Alastair Strachan RIPE NCC Communtiy Development Officer

1 0

IPv6 Addressing Considerations (IETF Internet-Draft)
by Fernando Gont 02 Jun '22

02 Jun '22

Hi, We have published a revision of our IETF Internet-Draft "IPv6 Addressing Considerations". It is available at: https://datatracker.ietf.org/doc/html/draft-gont-v6ops-ipv6-addressing-cons… It discusses a lot of practical considerations regarding IPv6 addressing, so we'd love to hear from you if there's any that we missed or that you think we got wrong. Abstract IPv6 addresses can differ in a number of properties, such as scope, stability, and intended usage type. This document analyzes the impact of these properties on aspects such as security, privacy, interoperability, and network operations, with the goal of providing guidance about IPv6 address usage. Additionally, it identifies challenges and gaps that currently prevent systems and applications from leveraging the increased flexibility and availability of IPv6 addresses. Thanks! Regards, -- Fernando Gont SI6 Networks e-mail: fgont(a)si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

1 0

IPv6 Guide
by Jens Link 20 May '22

20 May '22

Hi, about a month ago I was asked on Twitter if I new any good and current books ob IPv6. Apparently there is nothing current[1]. I came up with the idea of starting an OpenSource Guide on IPv6. I created a git repo: https://gitlab.com/jenslink/ipv6guide and also have (sponsored) hardware to run website, mailing list, ... There is not much yet, but I'll reserved a couple of hours per week for it starting in June. The project is hosted in gitlab (because they have IPv6) and will be written in markdown. For now I'd prefer to start with an English version and maybe add translations later. All we need is people to create, review and edit content. That means we need your help if you have some time to spare. If you have any question, just ask. I'm also around the RIPE meeting for the rest of the week. Jens [1] Which might not be a problem, Gert Doering just recycled an 11year old presentation with very little changes. -- ---------------------------------------------------------------------------- | Delbrueckstr. 41 | 12051 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink(a)quux.de | --------------- | ----------------------------------------------------------------------------

6 11

Ipv6 adress policy Musings
by Jetten Raymond 18 May '22

18 May '22

Dear IPv6 list members. The Address policy working group has asked for our input on the current address policies. Please have a look at the large list of questions, and please do participate in the discussion on the Address Policy working group list https://www.ripe.net/ripe/mail/archives/address-policy-wg/2022-May/013541.h… Rgds The ipv6 wg co chairs For Internal Use Only

1 0

RIPE 84 IPv6 WG Agenda
by Jetten Raymond 11 May '22

11 May '22

Hello All, Here is the current agenda for the RIPE 84 meeting in Berlin next week (also online). The IPv6 WG session will be on Thursday 19 May 2022 from 11:00 - 12:30 CET Co Chairs, * welcome, etiquette etc, acceptation of the minutes 5 min. Wilhelm Boeddinghaus * "IPv6 and the Windows 10 Firewall" (25 min incl Q&A) Paolo Volpato * "IPv6 Deployment Status: Update and Remaining Challenges". (20 min incl Q&A) Justin Lurman & Eric Vyncke * "Just Another Measurement of Extension header Survivability (JAMES)" (10 min incl Q&A) Eric van Uden Or collegue * IPv6 in the field Feld, KPI-results / and Or naming challenges IPv6 inside VPN (25 min incl Q&A) Co Chairs * round up, thanks 5 min Welcome onsite, or online ! 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

Second call for presentations IPv6 WG @RIPE84
by Jetten Raymond 12 Apr '22

12 Apr '22

Hello All, RIPE 84 will take place from 16-20 May 2022 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 Berlin. For both cases you can register here: https://ripe84.ripe.net/attend/register/ The IPv6 Working Group session is scheduled for , Thursday 19 May from 11:00 . 12:30 (UTC+1) We still have some time in our session. 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

1 0

Last call and final reminder for nominations to the 2022 Rob Blokzijl Award
by Carsten Schiefner 14 Mar '22

14 Mar '22

[Apologies for cross-posting to various RIPE lists] Dear IPv6 WG members - this is the last call and final reminder for nominations to the 2022 Rob Blokzijl Award that will be accepted until this Friday, 18th March, at 23:59 UTC. In seeking nominations for this prestigious award, which was created to celebrate Rob's contributions to the development of the Internet, the Award Committee (https://rob-blokzijl-foundation.org/2021/11/22/2022-award-committee/) is interested to receive nominations of those who have reflected Rob's approach in either a technical or operational capacity. Please give some consideration to nominating individuals - but also teams and groups of people! - in your own community and/or the wider industry in the RIPE region who, in your opinion, deserve to be recognised for their work to make the internet and/or internet community better. To specifically have this emphasised again after some according queries: nominations of teams and groups of people are very well possible and wished for as well in case their collective work would match the criteria of the call as laid out! The Award Committee is particularly interested to receive nominations of contributors who, in addition to their own contributions, have also supported and enabled others anywhere in the world. Also, the Award Committee would like to encourage those making nominations to consider not only the community members in the later stages of their careers or who are widely known but also those who may have contributed greatly in the springtime of their career or discreetly for the greater good or who may be considered to be part of an unrepresented group. And last but not least: those of you who previously have made a nomination other than Wilfried Woeber, the 2018 awardee, may want to consider resubmitting a nomination. The complete details of the call and the nomination process can be found at: https://rob-blokzijl-foundation.org/2021/11/25/call-for-nominations-2022/ Best wishes and kind regards Carsten (on behalf of the Award Committee)

1 0

Call for presentations for ripe 84
by Jetten Raymond 07 Mar '22

07 Mar '22

Hello All, RIPE 84 will take place from 16-20 May 2022 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 Berlin. For both cases you can register here: https://ripe84.ripe.net/attend/register/ The IPv6 Working Group session is scheduled for , Thursday 19 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. Hope to see many of you, On behalf of the IPv6-WG Benedikt, Jen, Ray

1 0

New on RIPE Labs: One Bit to the Left - An IPv6 Success Story
by Ewan Mackie 02 Mar '22

02 Mar '22

Dear colleagues, Back in December 2020, for the second time since we started allocating IPv6, the RIPE NCC granted a request for a subsequent /29 allocation. As moments like this are good indicators of how growth and demand for IPv6 is developing, we reached out to NetCologne GmbH to take a look back and learn more about their IPv6 story. The full interview is available here on RIPE Labs: https://labs.ripe.net/author/ewan-mackie/one-bit-to-the-left-an-ipv6-succes… <https://labs.ripe.net/author/ewan-mackie/one-bit-to-the-left-an-ipv6-succes…> Kind Regards, Ewan Mackie RIPE NCC

1 0

Hijacking unused address space for a private infrastructure - any legal consequences?
by Vasilenko Eduard 24 Feb '22

24 Feb '22

Hi all, Could somebody speak on the legal consequences of hijacking unused address space? Imagine the situation that some vendor would push many Carriers to use FC/8 by cutting a rather big block out of it (/28 for each Carrier). This address space should have a registry. It is an IANA property till then. But: 1. Nobody is using it - nobody would be hurt. 2. This prefix would be excluded from the Internet (by routing and filtering) 3. FC/8 is assumed to be used for the closed domain (the purpose of usage is very similar). Just nobody decided how exactly. Maybe /28 is not how IANA and IETF would want to split it in the future. People could ask "why not GUA"? The answer is: it is difficult to get yet another /28 GUA from RIR just for the infrastructure. /28 goal has the technical roots by itself. It is the sort of technical solution. Could such LIR/Carrier have any pressure from any RIR or IANA itself? Is any restriction in the LIR agreement? Any legal consequences? (that would push for renumbering). Of course, I am aware what may happen if Carrier would need to connect infrastructure with different Carrier or Cloud Provider Without proper random prefix generation and registry to guarantee uniqueness. The technical side is very clear for me. I am just very ignorant on the legal side. Disclaimer: This question is not related to Huawei, not at all. Eduard

3 8

Re: [ipv6-wg] Hijacking unused address space for a private infrastructure - any legal consequences?
by JORDI PALET MARTINEZ 24 Feb '22

24 Feb '22

Hi Eduard, I think we need to first understand that addresses aren't a property. If you get allocated or assigned resources by a RIR, they do not belong to you, you just have a yearly license to use them, and (typically) while the need is justified. Similarly, they aren't an IANA property, it is just the central registry that allocates the to the 5 RIRs. By the way, obtaining any prefix length, from any RIR, if justified is not difficult. And that justification for IPv6 is not usually a problem. If there are cases where the actual policy doesn't work, in any RIR (most of them have basically the same text), we should work in improving the policy. I'm not really sure legally something can be done ... Saludos, Jordi @jordipalet El 24/2/22 15:01, "ipv6-wg en nombre de Vasilenko Eduard via ipv6-wg" <ipv6-wg-bounces(a)ripe.net en nombre de ipv6-wg(a)ripe.net> escribió: Hi all, Could somebody speak on the legal consequences of hijacking unused address space? Imagine the situation that some vendor would push many Carriers to use FC/8 by cutting a rather big block out of it (/28 for each Carrier). This address space should have a registry. It is an IANA property till then. But: 1. Nobody is using it - nobody would be hurt. 2. This prefix would be excluded from the Internet (by routing and filtering) 3. FC/8 is assumed to be used for the closed domain (the purpose of usage is very similar). Just nobody decided how exactly. Maybe /28 is not how IANA and IETF would want to split it in the future. People could ask "why not GUA"? The answer is: it is difficult to get yet another /28 GUA from RIR just for the infrastructure. /28 goal has the technical roots by itself. It is the sort of technical solution. Could such LIR/Carrier have any pressure from any RIR or IANA itself? Is any restriction in the LIR agreement? Any legal consequences? (that would push for renumbering). Of course, I am aware what may happen if Carrier would need to connect infrastructure with different Carrier or Cloud Provider Without proper random prefix generation and registry to guarantee uniqueness. The technical side is very clear for me. I am just very ignorant on the legal side. Disclaimer: This question is not related to Huawei, not at all. Eduard -- 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 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

1 0

Announcing the Updated IPv6 Fundamentals E-Learning Course
by Pedro Vaz 20 Jan '22

20 Jan '22

Dear colleagues, Our updated IPv6 Fundamentals course is now live and available in the RIPE NCC Academy. The course aligns more with the IPv6 Fundamentals Analyst exam and has a fresh new look. We hope to see more network operators following best practices and developing their understanding of IPv6 policies through the course. The course consists of interactive modules and activities which help learners apply concepts using tools and realistic scenarios. You can find out more about the new IPv6 Fundamentals online course in the RIPE NCC Academy at: https://academy.ripe.net/ipv6-fundamentals I would like to thank everyone who participated in the course development process, for testing the exam, reviewing the course material and testing the activities. Having the involvement of the community is a major strength of our courses, and we thank all of our volunteers. If you have any questions or feedback, you can reach us at <exams at ripe.net>. Kind regards, Pedro Vaz Senior Technical Training and Development Officer

1 0

Announcing the Updated IPv6 Fundamentals E-Learning Course
by Pedro Vaz 20 Jan '22

20 Jan '22

Our updated IPv6 Fundamentals course is now live and available in the RIPE NCC Academy. The course aligns more with the IPv6 Fundamentals Analyst exam and has a fresh new look. We hope to see more network operators following best practices and developing their understanding of IPv6 policies through the course. The course consists of interactive modules and activities which help learners apply concepts using tools and realistic scenarios. You can find out more about the new IPv6 Fundamentals online course in the RIPE NCC Academy at: https://academy.ripe.net/ipv6-fundamentals I would like to thank everyone who participated in the course development process, for testing the exam, reviewing the course material and testing the activities. Having the involvement of the community is a major strength of our courses, and we thank all of our volunteers. If you have any questions or feedback, you can reach us at <exams at ripe.net>. Kind regards, Pedro Vaz Senior Technical Training and Development Officer

1 0

FYI: NCCoE Releases Draft Project Description for IPv6 Transition
by Jaap Akkerhuis 04 Jan '22

04 Jan '22

[NCCoE stands for the National Cybersecurity Center of Excellence] Some people on this list might be interested in this work. See the announcement: <https://content.govdelivery.com/accounts/USNIST/bulletins/2ffde66>. jaap

1 0

Minutes from the IPv6 WG @ RIPE 83
by Jetten Raymond 24 Dec '21

24 Dec '21

Hello, Here are the minutes from RIPE 83, if you have any comments or remarks, please let us know before 20.12 so we can have them published. RIPE 83 RIPE IPv6 Working Group Minutes Date: 25 November, 13:00-14:00 (UTC+1) Chairs: Raymond Jetten, Benedikt Stockebrand Scribe: Suzanne Taylor Status: Draft Welcome, Administrative Matters Raymond Jetten, Working Group Co-Chair Raymond Jetten, Working Group Co-Chair, welcomed everyone to the session and went over some rules of engagement. There were no questions or comments. Building IPv4 Islands for Fun and Profit Nico Schottelius, ungleich This presentation is available at: https://ripe83.ripe.net/wp-content/uploads/presentations/86-ripe83-ipv4-isl… Nico discussed the technical details of how to set up IPv6-only networks that need to incorporate IPv6-incompatible devices (such as x-ray or ultrasound scanners, LoraWAN gateways, printers, power plants) by setting up IPv4 "islands" for those devices. Benedikt Stockebrand commented that there are many different approaches to this issue and that if this particular method doesn't work, then attendees should be encouraged to reach out on the mailing list rather than simply give up on deploying IPv6. Nico said he fully agreed. Michael Richardson, Sandelman Software Works, thanked Nico for his explanation and said he had also been doing something similar. He said he thought another name is needed, however, other than "islands". Nico said he was open to other suggestions. Raymond suggested that ideas could be discussed on the mailing list. There were no further questions or comments. To ULA or not ULA Nico Schottelius This presentation is available at: https://ripe83.ripe.net/wp-content/uploads/presentations/87-ripe83-to-ula-o… In his second presentation, Nico gave an overview of ULAs (unique local addresses), which are used in community networks and other use cases but aren't generally visible on the Internet. He explained how his company has been asked to run a ULA registry and asked for opinions about how - and whether there was consensus - to support community projects by running a ULA registry. Jordi Palet Martínez, Moremar - The IPv6 Company, said that the right way to have a registry is to revive the ULA-Central work, which he tried already in the IETF and with the RIRs. He said there is possibly a need for a global policy on running a central IANA registry or coordination for that among the RIRs, but that it didn't work. He offered to continue working on that if there were community support. Nico said that was an interesting approach and that there were also recent discussions around where to register IP space for aerospace technology and that this could be a way to go, or that the RIRs could have a subsection for ULA community space. He said he would reach out to Jordi after the meeting. Niall O'Reilly, speaking as a "ULA user", asked Nico whether he imported registrations from SixXS to the new registry. Nico responded that everything had been imported and that some have already been deleted because they saw old information in the registry. Marco Hogewoning, RIPE NCC, said that the EU Cybersecurity Strategy suggests a possible sunset clause for IPv4 if insufficient progress is made with IPv6 and asked what the RIPE community thought could be done other than avoiding legislation to force a particular technical choice. He asked whether the community, for example, would advise forcing the use of IPv6 or discouraging the use (or forcing the disuse) of IPv4. He commented that this strategy is focuses on the market and not just the public sector. Nico said that is a difficult question. He said the market is already at play, given the increasing price of IPv4 and that some governments are going IPv6-only. He said that an RIR like the RIPE NCC can encourage IPv6 deployment, and that he sees a role for open-source solutions to support this shift and enable bottom-up development and innovation. Rüdiger Volk, my UNorganized self, said he remembered when Internet number resources were essentially available for free and the one registry was funded by the US federal government. He said that, in order to support communities that were outside of the very small Internet at the time that wanted to install TCP/IP locally or regionally with a limited view to interconnect globally, volunteers started to hand out things and get centrally registered space and create sub-registries. Essentially, he said, the RIPE NCC registry grew from there. He said he felt that if the address space you're using has enough free resources for everyone to be globally unique, then you should do that - but if the current ICANN anchored registry system doesn't offer a way for all communities to adequately address their needs, that should be a trigger to question how to do that. He said that, in some ways, the precursor to ULA was the RFC 1918 space, but it was meant to just be local and was not meant to require a registry (unless your enterprise network isn't connected to anything else and runs as a very closed system, in which case a local registry might be used). Nico said he saw Rüdiger's point and said that perhaps this work should be a community/volunteer effort. He said this topic already came up on the IETF mailing list, along with the usual question of who would pay for the project. He said the idea of handing out GUA (global unique addresses) was also discussed on the IETF mailing list, which he thought was good, as it would offer uniqueness along with global addressability. He added that sponsoring the address space is one thing, but sponsoring the work was another thing and being recognised, a third consideration. He encouraged anyone interested in contributing to the project to contact him. Peter Hessler, speaking as an "open source enthusiast", asked how much space the community should request from the RIPE NCC if it were to group together and form a LIR to request and manage IPv6 address space. Nico said you can start with a /32 and simply request another as needed, because the addresses don't need to be consecutive. Raymond added that you can get a /29 without any justification. Michael Richardson said he had been a proponent of a non-connected IPv6 space for a long time and that he had first come across this before in using it in a data centre through VPNs as a management network. He said that in his experience, these inevitably leak and when they do, you don't know who to tell. He said this was also why he doesn't like ULA random. He said that the value of Whois is high and provides a feeling that no one will come and do something terrible to you because you're using the address space. He also said the possibility of reverse DNS really matters in IPv6 space. For those reasons, he said he would like to have a registry but was agnostic as to whether it should be a /29 of carefully managed global address space that is unannounced in RPKI, or ULA central or fd/8 if that were ever to work. He said there should be a nominal, one-time fee to register the space. He said he oftens sees a need for this in equipment chassis and gave the example of a networked fishing boat. He said he would rather it wasn't RFC1918 but IPv6, and if there were too much paperwork, you could use 1.1 or 11 network because 1918 is on the other interface and using NAT, so you don't know what is there. He said engineers don't use IPv6 because they think they can't get it and don't use ULA random because they need something different for every boat (in the example), which is correct, but he said it should be within the network you own. He said the community needs to enable this and that a small registration fee should make it your own in perpetuity. Benedikt said that one use case that tends to be forgotten about, as most in the community are LIRs, is having a provider aggregated addresses and wanting to maintain some independence from your ISP, ULAs can be very helpful in renumbering. He said there's a big difference between IPv4 and IPv6 in that IPv6 was designed to support multiple addresses per interface, and this can be very useful. He also cautioned against starting a separate address space that is sort of connected with people using ULAs across the Internet via tunnels where they really shouldn't. Raymond closed the queue to further questions in the interest of time. RIPE-554bis Jan Žorž, 6connect This presentation is available at: https://ripe83.ripe.net/wp-content/uploads/presentations/73-RIPE554bis-RIPE… Jan gave some background and history on updating RIPE-554 and RIPE-554bis, which provides guidance on how to procure IPv6-capable equipment and software for enterprises. He explained which updates were deemed necessary, such as adding fundamental RFCs like "IPv6 over Ethernet" and removing BOUNDv6, as it no longer exists. There are new requirements for hosts and enterprise/ISP switches, and some other changes for routers, CPEs, mobile devices, load balancers and software. He stressed the need to publish an update to RIPE-554 as soon as possible and asked the group whether there was consensus on RIPE-554bis. Blake Willis, Zayo, asked whether RFC8950/RFC5549 BGP tunnel signalling was within the document's scope. Jan replied that it included IPv6-specific things and he would need to look into it. Sander Steffann, 6connect and RIPE-554bis co-author, said he was also not certain. Jan said he did not think RFC8950 was included but that they could consider it for the next version, as they didn't want to expand the scope of this version since it would take too long to update it. Éric Vyncke, Cisco and IETF but speaking mainly as an "IPv6 evangelist", said he couldn't find in the draft RIPE-554bis document Jan's reference during his presentation to not using a /64 and RFC8200 now including atomic/overlapping fragments. Jan said the RFC8200 was in the section on requirements for host equipment, and that it's basically the same document, just updated. Sander said he thought he found the section that Éric was referring to, which was from RFC7608 (IPv6 prefix length recommendations for forwarding), which mentions that prefix lengths longer than /64 must be supported in forwarding. Éric said the other two RFCs mentioned were removed from the RIPE-554bis document and that the presentation had not been updated to reflect the most recent Google doc. Christoph Berkemeier, DB Station & Service AG, asked whether Jan was aware of automated or semi-automated test scripts/environments for the recommendations. Jan responded that this was a mistake many people were making, and that the document was meant to be used as a template. He said that, for example, "if support for tunnelling and duo-stack is required, the device must support basic transition mechanisms for IPv6 hosts and routers" then it could be technically possible to build a script to test this, but you would need to include everything you want and need, which would be complicated. He said that you need to take the parts of the document that apply to your situation. But, he said, if someone wanted to build something like that, then he would be happy to include it. Sander said that Blake Willis was referring on the chat to the University of New Hampshire's independent testing lab. Jan said there are asterisks on some of the requirements in the draft policy that indicate they are being tested. Jan asked the collective whether there was consensus. Benedikt said that no one would complain if they wanted to do the work. Raymond said he was happy to move forward but suggested leaving the mailing list open until the following Wednesday for any other potential objections to consensus, which Jan agreed to. Jan and Raymond thanked everyone for their hard work. Raymond thanked the scribe and said that there had been no comments on the minutes from RIPE 82, which had been online for some time, so declared them approved. He said that he hoped to see everyone at a meeting in person soon and closed the session. Rgds, Ray

7 24

Ripe 554 bis = ripe 772 has been published
by Jetten Raymond 14 Dec '21

14 Dec '21

Hello members of the list, We have a new document published: Requirements For IPv6 in ICT Equipment https://www.ripe.net/publications/docs/ripe-772 A big thanks to the authors and all involved ! The IPv6 wg co-Chairs For Internal Use Only

1 0

RIPE554-bis now published as RIPE772
by Tim Chown 14 Dec '21

14 Dec '21

Hi, Many thanks to the RIPE support team, 554bis is now published: "Requirements For IPv6 in ICT Equipment” https://www.ripe.net/publications/docs/ripe-772 I wonder how long before the next refresh... Best wishes, Tim

1 0

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

Status of IPv6 and open points
by Paolo Volpato 25 Feb '21

25 Feb '21

Dear WG IPv6, We are writing to share with the RIPE community our research work on IPv6 and we would appreciate having feedback from you. If you find it useful, we are also available to present it at the next RIPE meeting in order to stimulate further discussion on this topic. In this regard, we have presented a draft in IETF V6OPS WG (https://datatracker.ietf.org/doc/draft-vf-v6ops-ipv6-deployment/) and it should be discussed during the coming IETF 110. In summary, the draft describes where the adoption of IPv6 stands in different domains (operators, enterprises, content providers, etc.), highlights possible steps to move the deployment of IPv6 forward, tries to stimulate the discussion on possible “calls for action” to further push the shift to IPv6, and presents some misconceptions as well as open points still to be faced related to that. Some key findings of our work show that open aspects still remain, for which we would be happy to have the feedback of the RIPE community: 1. IPv4 exhaustion: the total remaining IPv4 address pool, as reported by the five RIRs at the end of 2020, has a bit more than 18 million addresses (either available or reserved). This data is summarized for example in https://www.potaroo.net/ispcol/2021-01/addr2020.html. However, from the same article, it appears that the pool of unadvertised addresses has grown in the past few years. Quoting it: “From 2018 to the end of 2020 this pool rose to around 50 /8s that were unadvertised in the public Internet”. On the one hand this seems a good sign for IPv6 deployment (e.g. IPv4 addresses are released). On the other, we may suspect that the IPv4 addresses are more than expected and that available space could be used, for example, for transfers. We would like to have your opinion on this. 2. IPv6 performance (latency, packet loss) seems, in some cases, worse than IPv4. Clearly, the perception of “bad” performance (relatively) might have a negative influence over the adoption of IPv6. What is the opinion of the community on this point? 3. IPv6 for Enterprises and Vertical Industry also shows a low level of deployment that can be investigated. 4. More could also be added. We would be happy to discuss that with you. As said, we are also available to present our findings at the next RIPE meeting to bring it further. Many thanks in advance BR Paolo Paolo Volpato Senior IP Product Manager Europe Standardization & Industry Development Dept [2012 Labs] ____________________________________________________________________________ Huawei Technologies Address: via Lorenteggio 240, Torre A, 20147 Milano Italy Mobile: +39 344 019 7606 E-mail: paolo.volpato(a)huawei.com _____________________________________________________________________________ Huawei Technologies Italia S.r.l. is a company registered in Italy at the Company Registration Office of Milan, with registered number 04501190963 and equity capital €3,000,000 fully paid up, whose registered office is in Milan, Via Lorenteggio 257, Tower B, 20152 Milan. Huawei Technologies Italia S.r.l. is 100% owned by Huawei Technologies Cooperatief U.A _____________________________________________________________________________ This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- PRIVACY NOTICE: Pursuant to Art. 13 of Legislative Decree 196/03, so called "Data Protection Code", Huawei Technologies Italia Srl. informs you that the personal data provided by you will be treated for the acquisition of information preliminary to the conclusion of contracts, for the definition and formalization of contractual relationship with you as well as for their management and for the fulfillment of legal requirements related to civil, tax and accounting law. Data are processed both through computer or paper in a lawful and correct manner and in compliance with the Decree. Personal data and its processing are necessary for business negotiation and will not be subject to disclosure and spread out the circumstances permitted by law, on the same you can exercise your rights under art. 7 of the above mentioned decree. The Data Controller is Huawei Technologies Italia Srl, which has appointed Data Processors, the list of which is available at dataprotection(a)huawei.com<mailto:dataprotection@huawei.com>.

1 0

IPv6 WG Call for presentations RIPE82
by Jetten Raymond 15 Feb '21

15 Feb '21

Hello, RIPE82 will be virtual, from May 17th till may 21th. The IPv6 Working Group is tentatively scheduled for May 20th, 10:30 - 12:00 CET (UTC+2). We are looking for talks - please email ipv6-wg-chair at ripe.net<https://lists.ripe.net/mailman/listinfo/ipv6-wg> if you'd like to present. Thanks! Jen, Benedikt, Ray

1 0

Address Assignment Practices in IPv4 and IPv6
by Stephen Strowes 21 Jan '21

21 Jan '21

Hi all, We've published a study on the stability of IPv4/IPv6 assignments in domestic ISPs, and the size of the IPv6 prefixes that networks typically assign to subscribers. We look at this from two different angles: what can we measure from RIPE Atlas, and what do operators state in the RIPE Database? In particular, understanding the size of IPv6 delegated prefixes is important for applications such as host reputation & blocklists, geolocation, and research on network measurement. The RIPE Database offers the community a way to share information on their prefix delegations, and deserves some attention! Read more here: https://labs.ripe.net/Members/stephen_strowes/address-assignment-practices-… Cheers, S.

1 0

Fwd: IPv6 Addressing Considerations
by Fernando Gont 14 Dec '20

14 Dec '20

Folks, FYI: https://tools.ietf.org/html/draft-gont-v6ops-ipv6-addressing-considerations Comments welcome. :-) Thanks! Cheers, Fernando -------- Forwarded Message -------- Subject: IPv6 Addressing Considerations Date: Fri, 11 Dec 2020 13:07:04 -0300 From: Fernando Gont <fgont(a)si6networks.com> To: IPv6 Operations <v6ops(a)ietf.org> Folks, We have published a new Internet-Draft entitled "IPv6 Addressing Considerations". It is available at: https://www.ietf.org/archive/id/draft-gont-v6ops-ipv6-addressing-considerat… The Abstract of the I-D is: IPv6 addresses can differ in a number of properties, such as scope, stability, and intended usage type. This document analyzes the impact of these properties on aspects such as security, privacy, interoperability, and network operations. Additionally, it identifies challenges and gaps that currently prevent systems and applications from leveraging the increased flexibility and availability of IPv6 addresses. We have discussed this topic with some of you off-list, and part of those comments still need to be incorporated (apologies for the delay!). However, we felt that this -00 version already contains quite a bit of material for discussion. (and given that there have been other recent threads related to IPv6 addressing on this list and on 6man@, we felt it would be timely to get this -00 version posted now). Your comments will be very welcome. Thanks! Regards, -- Fernando Gont SI6 Networks e-mail: fgont(a)si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

1 0