- ipv6-wg - mailman.ripe.net

APRICOT 2025: Call for Papers
by Mark Tinka 28 Oct '24

28 Oct '24

Hello all. The APRICOT 2025 Programme Committee is now seeking contributions for Presentations and Tutorials for the APRICOT 2025 Conference, which will be held in Petaling Jaya, Malaysia, 19th - 27th, February 2025. Details about the Call for Papers, and how you can submit a proposal for a conference, peering and tutorial talk, and the submission deadlines, can be found at the link below: https://2025.apricot.net/programme/callforpresentations We look forward to receiving your papers, and seeing you in Malaysia. Many thanks! Mark Tinka, Achie Atienza & Mark Duffell APRICOT 2025 Programme Committee Chairs

1 1

APRICOT 2025: Call for Program Committee Volunteers
by Mark Tinka 26 Oct '24

26 Oct '24

Hello all. The APRICOT 2025 Organising Committee would like to welcome everyone to join us in Petaling Jaya, Malaysia, from the 19th to the 27th, February 2025. The APRICOT 2025 Programme Committee is responsible for the solicitation and selection of suitable presentations and tutorial content for the APRICOT 2025 conference (https://2025.apricot.net/). We are now seeking VOLUNTEERS from the community to join the APRICOT 2025 PC to assist with the development of the programme for APRICOT 2025. Eligible PC candidates must have attended recent APRICOT events, have broad technical knowledge of Internet operations, and have good familiarity with the format of APRICOT. Having constructive opinions and ideas about how the programme content might be improved is of high value too. PC members are expected to work very actively to solicit content, follow-through for speaker updates and review submissions for technical merit . The PC meets by conference call, weekly in frequency during the three months prior to APRICOT. While participation in the weekly calls is not obligatory, active participation in content reviews is required at all times to help the PC reach consensus. PC members who are unable to fully participate in the programme development will be excused from the PC. If you are interested in joining the PC and meet the above eligibility criteria, please send a brief note to "pc-chairs at apricot.net". The note must include affiliation (if any) and a brief description about why you would make a good addition to the PC. The PC Chairs will accept nominations received by 17:00 UTC+8 on Sunday 27th October 2024, and will announce the new PC shortly thereafter. Many thanks! Mark Tinka, Achie Atienza & Mark Duffell APRICOT 2025 Programme Committee Chairs

1 0

IPv6 WG agenda for RIPE89
by Christian Seitz 18 Oct '24

18 Oct '24

Dear IPv6 working group, we have some great presentations for the IPv6 WG session in Prague. The session will take place on Thursday 31 October 2024 from 9:00 - 10:30 CET. The agenda will also be published in the RIPE89 meeting plan [1] soon. This is our current agenda: 1. Welcome [3 min] * Opening and Welcome * Approval of RIPE 88 Minutes * Microphone Etiquette 2. Why is this IPv6 transition taking so long? [25+5 min] Geoff Huston 3. K8s IPv6 and Routing [15+5 min] Nico Schottelius 4. Advent of IPv6 [10+5 min] Jens Link 5. What we have achieved so far [15+5 min] Benedikt Stockebrand 6. Thanks, Wrap Up and Rate the Talks [2 min] If there are any changes to this agenda we will send an update and also update the meeting plan on the website [1]. [1] https://ripe89.ripe.net/programme/meeting-plan/ Many thanks also to all of you who suggested a presentation but were unable to present due to the full agenda. On behalf of the IPv6 WG co-chairs, Nico, Ray and Chris

1 0

BCP/BCOP for ipv6 deployment and filtering policy
by Sheikh Md Seum 15 Oct '24

15 Oct '24

Hello all, I'm trying to deploy IPv6 in a small ISP of Italy (AS203847). While going through the deployment procedure I was not able to find any BCP/BCOP regarding how to filter ICMPv6, what standards should be followed. For enterprise there exists RFC7381. Even though there are lot of similarities between enterprise and ISP there exists some differences. Small ISP with less human resource might find security considerations addressed on RFC9099, address planning mentioned in RIPE-690 a bit difficult to follow. So, what is your opinion to create a BCP/BCOP combining all these RFC and make it more easier to follow while deploying IPv6 in an ISP? If something like this already exists or someone already working, it will be really helpful if someone shares. --- Regards Sheikh.

10 16

Presentation Proposal
by Benedikt Stockebrand 15 Oct '24

15 Oct '24

Hi guys, as Chris asked me (some time ago---some things just won't change...) here's a first draft of a proposal for a presentation in Prague: "The road ahead: Where are we with IPv6, and what needs to be done next?" We've been aiming at a 15 minute slot, but as always I've got more than enough to talk about if you have more time to fill. (Ray probably remembers how I prepared a presentation overnight because Fernando hadn't even registered to the meeting in Rotterdam(?) until hours before his slot...) Anyway, what might actually stir up some discussion is that we may get into serious problems with the size of the IPv6 routing table in the default free zone. Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Stepladder IT Training+Consulting GmbH Benedikt Stockebrand Fichardstr. 38, 60322 Frankfurt/Main Dipl.-Inform./Geschäftsführer HRB 94202, Registergericht Frankfurt/M contact(a)stepladder-it.com http://www.stepladder-it.com/ +49 (0) 69 - 247 512 362 BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/ Bitte kein Spam, keine unaufgeforderten Werbeanrufe, keine telefonischen Umfragen. Anrufe werden ggf. zu rechtlichen Zwecken aufgezeichnet. No spam, no unsolicited sales calls, no telephone surveys, please. Calls may be recorded for legal purposes.

2 1

NL consultation on IPv6
by Romain Bosc 25 Sep '24

25 Sep '24

Dear all, Flagging that the Dutch Standardisation Forum is having a consultation on IPv6. Here is the link to the consultation and relevant documents (in Dutch): https://internetconsultatie.nl/ipv6/b1 To note, comments in English are also welcomed, and the deadline is on 4 October 2024. In a nutshell, the Standardisation Forum [which supports the Dutch government in the development, use and deployment of open standards] -- is currently assessing the scope of application of the 'apply or explain' list covering IPv6 and whether additional clarification is needed. In this context, a document gathering recommendations from an expert group has been published and is available on the webpage of the consultation. The current scope is: *IPv6 and IPv4 must be applied in combination (‘dual stack’) to communication between applications in (a) network(s).* The expert group recommends clarifying the scope as follows: “*IPv6 must be applied to digital services, such as websites and e-mail servers. In addition, end-user devices must be able to reach websites, applications and other digital services on the Internet via IPv6. If necessary, it is allowed to additionally apply IPv4 (dual stack).*” It also recommends changing the name (caption) on the list from “IPv6 and IPv4” to “IPv6”. Let us know if you have any questions or comments. All best, Romain -- Romain Bosc Sr Public Policy & Governance Officer RIPE NCC E: rbosc(a)ripe.net

1 0

Call or IPv6 WG presentations at RIPE 89
by Raymond Jetten 14 Sep '24

14 Sep '24

Hello All, RIPE 89 will be held in Prague, Czechia from 28 Oktober - 1 November 2024, as well as online. For any participation form you can register here https://ripe89.ripe.net/attend/register/ The IPv6 Working Group session is scheduled for Thursday 31 Oktober from 9:00 . 10:30 (UTC+1) We are looking for presentations - please email : ipv6-wg-chair (at) ripe.net if you'd like to present. Please also state if you intend to be online or onsite, and the duration of your presentation, and a short description of it. Once we have decided on the agenda, we'll contact the presenters closer to the meeting . Hope to see many of you, On behalf of the IPv6-WG Christian, Nico, Ray For Internal Use Only

2 1

Survey for operators on IPv6 Extension Headers
by Justin Iurman 04 Sep '24

04 Sep '24

Hi everyone, TL;DR We're still trying to collect more responses from operators, please take a look at the survey [1]. This survey is anonymous (you and your responses), does not require login, and is quite short. On behalf of the University of Liege (Belgium), we've been doing measurements on IPv6 Extension Headers over the last two/three years. More specifically, we're trying to evaluate how they are processed by routers along the path, and so from the edge. Now, we would like to compare our observations with the reality of operators. For that, we propose this very short survey [1] to operators and would really appreciate if you could complete it. Note that we guarantee anonymity of your answers. If you're interested, we may share some results anonymously once the dataset is big enough. Looking forward to your input. Thanks, Justin [1] https://docs.google.com/forms/d/1SqPjLFe0TrWGJHqbBLZsrobiss1s3VR4Q3kbQ3ro4tk

1 0

New special purpose IPv6 prefixes allocated by IANA
by Christian Seitz 24 Jul '24

24 Jul '24

Dear IPv6 WG list members, IANA hast allocated some new special purpose IPv6 prefixes in the last months [1]. Two have already been allocated before the last RIPE meeting and one has been allocated yesterday. This may need filtering at the network edges. 3fff::/20 -> Documentation Abstract from the the IETF document [2]: "The document describes the reservation of an additional IPv6 address prefix for use in documentation. This update to RFC 3849 expands on the existing 2001:db8::/32 address block with the reservation of an additional, larger prefix. The addition of a /20 allows documented examples to more closely reflect a broader range of realistic, current deployment scenarios and more closely aligns with contemporary allocation models for large networks." 5f00::/16 -> Segment Routing (SRv6) SIDs Abstract from the the IETF document [3]: "The data plane for Segment Routing over IPv6 (SRv6) is built using IPv6 as the underlying forwarding plane. Due to this underlying use of IPv6, Segment Identifiers (SIDs) used by SRv6 can resemble IPv6 addresses and behave like them while exhibiting slightly different behaviors in some situations. This document explores the characteristics of SRv6 SIDs and focuses on the relationship of SRv6 SIDs to the IPv6 Addressing Architecture. This document allocates and makes a dedicated prefix available for SRv6 SIDs." 2001:1::3/128 -> DNS-SD Service Registration Protocol Anycast Address Abstract from the the IETF document [4]: "The Service Registration Protocol for DNS-Based Service Discovery uses the standard DNS Update mechanism to enable DNS-Based Service Discovery using only unicast packets. This makes it possible to deploy DNS Service Discovery without multicast, which greatly improves scalability and improves performance on networks where multicast service is not an optimal choice, particularly IEEE 802.11 (Wi-Fi) and IEEE 802.15.4 networks. DNS-SD Service registration uses public keys and SIG(0) to allow services to defend their registrations." [1] https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-speci… [2] https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc3849-update/05/ [3] https://datatracker.ietf.org/doc/draft-ietf-6man-sids/06/ [4] https://datatracker.ietf.org/doc/draft-ietf-dnssd-srp/25/ Kind regards Chris

1 0

IPv6-only mostly deployments and Google Chromecast Audio
by Mick O'Donovan 23 Jul '24

23 Jul '24

Good morning all, I have a question about chromecast audios [https://www.whathifi.com/google/chromecast-audio/review] and their operation on an IPv6-only mostly LAN. Several months ago, following the great tutorial Ondřej Caletka from the RIPE NCC did and then the talk Jen Linkova did in Tuesday's plenary at RIPE87 in Rome, I deployed a new Vlan in my home network to test the use of option 108 etc. It worked a treat to the point where I believed I'd tested any potential corner cases and so a few weeks back I transitioned to deploying it on my main home network vlan. Once again I thought everything worked a treat and got no complaints until recent days when my wife tried to stream some music to an old chromecast audio device we use to connect to some wired ceiling speakers. Having looked into the issue it would appear that the chromecast audio can't/won't do v6 and this is something that caught me on the hop a little. Those devices that are dual-stacked continue to see and can make use of this chromecast audio but those devices that are happily working away and utilising the option 108 to not have v4 (such as my wife's mobile device) can no longer see/communicate with the chromecast. I guess my question out of all of this is if any of you have run up against this particular problem and if so what was your solution. I suppose in theory it doesn't need to be a chromecast, I guess any device that's unable or unwilling to use v6. How have you managed direct communications between two devices on the same LAN segment whereby one device is doing v6 only and the other refuses to use v6 and will only use v4? I'd dearly love to avoid having to turn off option 108 on the main network. Thanks, -- Mick O’Donovan Senior Network Engineer HEAnet CLG Ireland's National Education and Research Network 3rd Floor, North Dock 2 | 93/94 North Wall Quay | Dublin D01 V8Y6 | Ireland +353 1 6609040 | mick.odonovan(a)heanet.ie | www.heanet.ie Registered in Ireland, No. 275301 | CRA No. 20036270

2 1