- ipv6-wg - mailman.ripe.net

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