- ipv6-wg - mailman.ripe.net

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