- ipv6-wg - mailman.ripe.net

Minutes of ripe81
by Jetten Raymond 17 Nov '20

17 Nov '20

Dear Working group, Below are the draft minutes from ripe 81. If you have any comments or remarks please let us know by replying to this email. A big thanks to Nikolas for doing the scribe. If we do not hear any comments these minutes will be published in about 2 weeks from now. Rgds, Ray, Jen, Benedikt. IPv6 Working Group Minutes - RIPE 81 Date: 29 October 2020, 13:00 - 13:45 WG Chairs: Benedikt Stockebrand, Jen Linkova, Raymond Jetten Scribe: Nikolas Pediaditis Status: Draft Welcome - Agenda Bashing The Chairs The minutes of IPv6 Working Group session from RIPE 80 were accepted as final. There were no questions or comments. RIPE554-bis - Tim Chown The presentation is available here: https://ripe81.ripe.net/presentations/58-ripe81-ipv6wg-ripe554bis-final.pdf Dmitry Serbulov (Alpha Net Telecom LTD) asked if it would be possible to share material with attendees prior to the start of each session. Raymond Jetten suggested that he should join the IPv6 WG mailing list. Bringing IPv6 Everywhere - Nico Schottelius The presentation is available here: https://ripe81.ripe.net/presentations/73-ripe81-bringing-ipv6-everywhere.pdf Ondrej Caletka (RIPE NCC) asked if connectivity will break if the host network becomes dual-stacked, or at worst, if the host network becomes IPv6-only. Nico replied that it wouldn't. IPv4 connectivity would still be available, and IPv6 would be added to it. Kurt Kayser (BDBOS) asked if geo-IP will always show that the VIIRB-users are in Switzerland. Nico Schottelius replied that at the moment, yes. And there is a bracket opening as soon as they are able to talk better to the RIPE API to change the registration of the /48 networks. It will be easy to actually assign the network to your location. Christoph Berkemeier (DB Station&Service AG) asked if the IPv6 distribution is stateless only. Nico confirmed that it is stateless at the moment but that could be changed if desired. Veronica McKillop (UK IPv6 Council) asked where the device is being manufactured. Nico replied that it's manufactured in China and shipped to and configured in Switzerland. Dmitry Serbulov (Alpha Net Telecom LTD) asked if open source software is used between the device and the server it connects to. Nico said that the software used, WireGuard and OpenWRT at the moment, are fully open source. Vesna Manojlovic (RIPE NCC) mentioned that a hackathon about RIPE Atlas software probes is taking place in November. She asked if Nico would be interested in joining and seeing how they could combine his router with RIPE Atlas software probes if possible. Nico replied that it would be a really cool project. Christoph Berkemeier (DB Station&Service AG) asked if there is a virtual appliance to enable legacy hosters. Nico replied that it builds on top of your existing IPv4 network so everything that's legacy continues to work. It's not a replacement. The nice thing about IPv6 is that although it is incompatible to IPv4 this also means that it runs in parallel to the existing infrastructure, allowing the legacy network to continue to work. Recent Improvements in IPv6 Addressing - Fernando Gont The presentation is available here: https://ripe81.ripe.net/presentations/72-fgont-ripe81-ipv6-wg-ipv6-addressi… Osamah Barakat (Siemens AG) asked if Windows 10 supports the latest IPv6 RFC or it is only Linux-based OS that support seen in the slide. Fernando Gont replied that it's surprising that they don't support RFC 7217 as one the authors worked for Microsoft. They also haven't implemented the update of 4941 either. However, he was less concerned about 4941, as compared to the support for 7217, as it has not been published as an RFC. End of the session.

1 0

Re: [ipv6-wg] RIPE554-bis
by Eric Vyncke (evyncke) 31 Oct '20

31 Oct '20

Trying to reply to all previous email messages in one email ;-) Look for EV> -éric-happy-to-see-this-initiative -----Original Message----- From: ipv6-wg <ipv6-wg-bounces(a)ripe.net> on behalf of Tim Chown via ipv6-wg <ipv6-wg(a)ripe.net> Reply-To: Tim Chown <Tim.Chown(a)jisc.ac.uk> Date: Wednesday, 28 October 2020 at 18:19 To: "ipv6-wg(a)ripe.net" <ipv6-wg(a)ripe.net> Subject: [ipv6-wg] RIPE554-bis Hi, I’m posting here as a heads-up that an effort has begun to revise RIPE-554, involving the original authors, myself and Tim Winters. We have a 5 min slot tomorrow in the 1pm CET IPv6 WG session to flag the work, to solicit input. The original publication was back in November 2010 with RIPE-501, which was updated in June 2012 with RIPE-554. There’s many references that have been obsoleted, and potentially much to add or remove. References to 2G cellular date the document. We’d like to begin by addressing the more strategic / structural questions. Such high level questions include: - Is there agreement to progress a –bis version now? Eight years have passed, people ask for guidance… EV> YES, please do ! knowing that RIPE554 was already a -bis, I would prefer a 501-ter though ;-) - Should we keep the scope to (largely) enterprise or expand it? If so, to what? EV> large/medium enterprise should indeed be the focus, consumer do not care and (wishful thinking ?) providers know better. Although, that I would love to see the IPv6 check-list for a smart TV ;-) - Is the linkage to the IPv6 Ready Logo programme still desired? EV> a couple of months ago, I check with several end-users and vendors, and, yes, it is still important (to be surprise to be honest, sorry Tim W) - Are there new classes of equipment to add, e.g. IoT/low power, WiFi controllers, …? EV> perhaps extend to applications? Cloud providers ? Perhaps remove consumer switch, load balancer, and network security ? - Are specific sections outdated, or are there significant new sections to add? EV> many "recents" RFC (including RFC 8200), focus on RA extensions - Should we add guidance on applying the content to different use cases? As separate docs? Appendices? We’ve currently working on the -bis as a Google doc, for which there’s a PDF of the current snapshot available from: https://go6.si/wp-content/uploads/2020/10/RIPE554-bis-v_01.pdf For now, please comment to the list, and maybe start a new thread for new topics. Tim

1 0

ip address pricing and protocol selection
by Wolfgang Zenker 31 Oct '20

31 Oct '20

Hello WG, I have a question for those of you that offer some kind of hosting. Do you charge your customers extra for IPv4 or IPv6 addresses? And if you have changed your policy on that recently, did that change your customers behaviour regarding their choice on ordering and publishing IPv4 / IPv6 addresses for the hosted services? Reason for asking: At our own hosting services we started out offering dual stack by default some 6 years ago, moved to ipv6-only by default about 2 years ago and since about one year we are charging extra for IPv4 addresses. This has led to a change in behaviour in our customer base, and I want to see if others are seeing similar changes or a different situation. You can reply off-list and I will summarize the results to the group. Please state if I should mention your name in the summary. Greetings, Wolfgang Zenker -- punkt.de GmbH Tel. +49 721 9109-500 Fax: -100 .infrastructure info(a)punkt.de https://infrastructure.punkt.de/ Kaiserallee 13a CEO: Jürgen Egeling, Daniel Lienert, Fabian Stein D-76133 Karlsruhe AG Mannheim HRB 108285

2 1

RIPE554-bis
by Tim Chown 30 Oct '20

30 Oct '20

Hi, I’m posting here as a heads-up that an effort has begun to revise RIPE-554, involving the original authors, myself and Tim Winters. We have a 5 min slot tomorrow in the 1pm CET IPv6 WG session to flag the work, to solicit input. The original publication was back in November 2010 with RIPE-501, which was updated in June 2012 with RIPE-554. There’s many references that have been obsoleted, and potentially much to add or remove. References to 2G cellular date the document. We’d like to begin by addressing the more strategic / structural questions. Such high level questions include: - Is there agreement to progress a –bis version now? Eight years have passed, people ask for guidance… - Should we keep the scope to (largely) enterprise or expand it? If so, to what? - Is the linkage to the IPv6 Ready Logo programme still desired? - Are there new classes of equipment to add, e.g. IoT/low power, WiFi controllers, …? - Are specific sections outdated, or are there significant new sections to add? - Should we add guidance on applying the content to different use cases? As separate docs? Appendices? We’ve currently working on the -bis as a Google doc, for which there’s a PDF of the current snapshot available from: https://go6.si/wp-content/uploads/2020/10/RIPE554-bis-v_01.pdf For now, please comment to the list, and maybe start a new thread for new topics. Tim

7 9

Rquirements for VPN
by christian bretterhofer 29 Oct '20

29 Oct '20

After reading https://go6.si/wp-content/uploads/2020/10/RIPE554-bis-v_01.pdf I see VPNs as part of the Network Security Equipment. But in my opinium there is not enough definition to be a VPN quality criteria. VPN external Protocol Must support IPv6 clients to IPv6 servers (6-to-6) ( Ipv6 Only) VPN external Protocol Must support IPv4 clients to IPv4 servers (4-to-4) (Ipv4 only) Transport inside of VPN VPN inner Protocol Must support IPv6 clients to IPv6 servers (6-to-6) VPN inner Protocol Must support IPv4 clients to IPv4 servers (4-to-4) VPN inner Protocol should support Dual stack. VPN inner Protocol should support 4in6 6in4 (transition protocols) The Idea from wireguard is maybe also a should the external protocol switch from Ipv6 to Ipv4 or Ipv4 to Ipv6 then the inner protocol should stay connected. Protocols with DNS64/NAT64 support would also help. maybe it fist into this recommendation document. -- --- best regards Christian Bretterhofer Enterprise User:

3 2

Minutes from ripe 80
by Jetten Raymond 28 Oct '20

28 Oct '20

Hi, We have published the RIPE 80 minutes as draft here: https://www.ripe.net/participate/ripe/wg/active-wg/ipv6/minutes/ipv6-workin… Let me know if these need any changes or corrections. Rgds, Ray

1 0

IPv6 WG @ RIPE81 Agenda
by Jen Linkova 07 Oct '20

07 Oct '20

The agenda for the IPv6 WG session at RIPE81 has been published: https://ripe81.ripe.net/programme/meeting-plan/ipv6-wg/ Thanks to everyone who submitted a talk - this time we got really overbooked so my apologies if your talk was not accepted! See you in 3 weeks! -- SY, Jen Linkova aka Furry

1 0

New on RIPE Labs: A Look Into the Tor Network Work on Supporting IPv6
by Alun Davies 01 Oct '20

01 Oct '20

Dear colleagues, With support from the RIPE NCC Community Projects Fund 2019, the Tor project has implemented IPv6 support across its network. Read how the work they've done will help make sure users across the RIPE NCC service region will have a more reliable experience on the Tor network: https://labs.ripe.net/Members/tor_grants/a-look-into-the-tor-network-work-o… Kind regards, Alun Davies RIPE NCC

1 0

IPv6 WG@RIPE81: Call for Presentations
by Jen Linkova 18 Sep '20

18 Sep '20

Hello, RIPE81 will be virtual, from Oct 27th till Oct 30th. IPv6 Working Group is tentatively scheduled for Oct 29th, 13:00 - 13:45. We are looking for talks - please email ipv6-wg-chair(a)ripe.net if you'd like to present. Thanks! -- SY, Jen Linkova aka Furry

1 1

[news] The IPv6 Fundamentals – Analyst Exam Is Live
by Sandra Bras 17 Aug '20

17 Aug '20

Dear colleagues, The IPv6 Fundamentals – Analyst exam is now live! You can use your LIR’s vouchers to schedule a RIPE NCC Certified Professionals exam using our online exam platform. The IPv6 Fundamentals - Analyst exam is intended for individuals who are familiar with best current practices in IPv6. It certifies your ability to calculate IPv6 subnets, create an IPv6 addressing plan and recognise the application of IPv6 transition mechanisms, among other skills. We would like to thank the RIPE community members who supported the exam creation process by writing and reviewing questions, and also answering our Job Task Analysis survey. You can find out more about the IPv6 Fundamentals – Analyst badge at: https://www.ripe.net/support/certified-professionals/ipv6-fundamentals-anal… <https://www.ripe.net/support/certified-professionals/ipv6-fundamentals-anal…> As for us here at Learning and Development, we’re getting back to work on our next exam – IPv6 Security Expert, which we expect to launch towards the end of 2020 or early 2021. All the best for the exam! Best regards, Sandra Bras Assistant Manager, Learning and Development RIPE NCC

1 0

IPv6 Exam Guide is Available
by sbras＠ripe.net 04 Aug '20

04 Aug '20

Dear colleagues, We’re putting the finishing touches on the first IPv6 exam in RIPE NCC Certified Professionals – “IPv6 Fundamentals – Analyst”. This exam is intended for people who are familiar with IPv6 best current practices and certifies your ability to calculate IPv6 subnets, create an IPv6 addressing plan, and recognise the application of specific IPv6 transition mechanisms, among other skills. Many of you have already shown interest in this exam. As requested, we’ve made the study guide available in advance so you can start preparing. You can read more about the exam and download the study guide here: https://www.ripe.net/support/certified-professionals/ipv6-fundamentals-anal… We will let you know when exam scheduling is available. Best regards, Sandra Sandra Bras Assistant Manager, Learning and Development RIPE NCC

1 0

Fwd: [v6ops] Question about "Operational Implications of IPv6 Packets with Extension Headers"
by Fernando Gont 29 Jul '20

29 Jul '20

Folks, FYI. The document is this one: https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-04 And the request input should be directed to <v6ops-chairs(a)ietf.org>, following the instructions described bellow. Thanks! Cheers, Fernando -------- Forwarded Message -------- Subject: [v6ops] Question about "Operational Implications of IPv6 Packets with Extension Headers" Date: Tue, 28 Jul 2020 22:55:45 -0700 From: Fred Baker <fredbaker.ietf(a)gmail.com> Reply-To: V6Ops-Chairs <v6ops-chairs(a)ietf.org> To: IPv6 Operations <v6ops(a)ietf.org> It looks like Fernando (et al) revised this and posted draft -04 on Saturday, and there has been a flurry of discussion. I haven't been through the document or the entire thread yet, but I do observe that a number of people have comments, and several people have expressed interest in the document. Let me ask the obvious question: you we want to adopt this as a working group draft? I won't ask you to hum; whether you wish to say "yes", "no", or "abstain", please reply to this email *privately* (which is to say, to v6ops-chairs) with that word prepended on the subject line. I'll give us 48 hours, which is to say that I will evaluate and state the result Thursday evening Pacific time. https://mailarchive.ietf.org/arch/search/?qdr=a&q=%22draft-gont-v6ops-ipv6-… https://mailarchive.ietf.org/arch/search/?qdr=a&q=%22Operational Implications of IPv6 Packets with Extension Headers%22 https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-drops https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops "Operational Implications of IPv6 Packets with Extension Headers", Fernando Gont, Nick Hilliard, Gert Doering, Warren Kumari, Geoff Huston, 2020-07-25, _______________________________________________ v6ops mailing list v6ops(a)ietf.org https://www.ietf.org/mailman/listinfo/v6ops

1 0

Join us for the RIPE NCC Educa::IPv6-only
by Ondřej Caletka 08 Jun '20

08 Jun '20

Dear IPv6 working group, You are invited to join us for a deep-dive into an IPv6-only world! We’re hosting the fourth edition of a RIPE NCC::Educa - a one day online event, bringing together experts from around the world to take a deeper look at topics of interest. Registration is free. To mark the anniversary of World IPv6 Launch Day, we’re hosting the RIPE NCC::Educa IPv6-only on Monday, 8 June from 10:00 UTC+2 onwards. Expert presenters will talk about what it means to run IPv6-only data centres, ISPs and enterprises, among other topics. You can view the agenda at: https://www.ripe.net/support/training/ripe-ncc-educa/ripe-ncc-educa-ipv6-20… Register at: https://www.eventbrite.nl/e/ripe-ncceduca-ipv6-only-tickets-106761053184 We hope to see you online soon! Best regards, Ondřej Caletka RIPE NCC

16 43

New on RIPE Labs: IPv6 Adoption Statistics: a Comparison of Different Metrics
by Mirjam Kuehne 08 Jun '20

08 Jun '20

Dear colleagues, In this new article on RIPE Labs we're looking at IPv6 adoption statistics provided by various organisations. How far do they match, and if not, why not? https://labs.ripe.net/Members/wilhelm/ipv6-adoption-statistics-a-comparison… Please note the link to the interactive maps that allow for a quick visual comparison of the results. If you have any feedback or additional information about these results, we welcome input in the comment section below the article. Kind regards, Mirjam Kühne RIPE NCC

1 0

Fwd: slaac-renum: New rev of draft-gont-6man-slaac-renum (Fwd: New Version Notification for draft-gont-6man-slaac-renum-08.txt)
by Fernando Gont 19 May '20

19 May '20

Folks, This is one of the documents I presented at the last RIPE IPv6 WG meeting. Thought you might be interested. Thanks! Cheers, Fernando -------- Forwarded Message -------- Subject: slaac-renum: New rev of draft-gont-6man-slaac-renum (Fwd: New Version Notification for draft-gont-6man-slaac-renum-08.txt) Date: Tue, 19 May 2020 03:38:18 -0300 From: Fernando Gont <fgont(a)si6networks.com> To: 6man(a)ietf.org <6man(a)ietf.org> Folks, We have posted a revision of draft-gont-6man-slaac-renum. It is available at: https://www.ietf.org/internet-drafts/draft-gont-6man-slaac-renum-08.txt The main changes incorporated in this version are: * We have eliminated the counter-based algorithm from Section 4.5 Previous revisions of the draft contained two alternative algorithms in Section 4.5: a counter-based algorithm, and a timer-based algorithm. The timer-based algorithm is more robust and simple, so it didn't make sense to keep the counter-based algorithm. (Kudos to Philip Homburg for "pushing" us to improve the algorithm). * Clarified the terminology used in the document This is a rather minor detail. We simply have spelled out that throughout the document, "GUAs" refer to "globally reachable" addresses (as opposed to ULAs). The diff from the last rev is available at: https://tools.ietf.org/rfcdiff?url2=draft-gont-6man-slaac-renum-08.txt As always, your feedback will be appreciated. Thanks! Cheers, Fernando -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-6man-slaac-renum-08.txt Date: Mon, 18 May 2020 23:25:39 -0700 From: internet-drafts(a)ietf.org To: Richard Patterson <richard.patterson(a)sky.uk>, Jan Zorz <jan(a)go6.si>, Fernando Gont <fgont(a)si6networks.com> A new version of I-D, draft-gont-6man-slaac-renum-08.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-6man-slaac-renum Revision: 08 Title: Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events Document date: 2020-05-18 Group: Individual Submission Pages: 24 URL: https://www.ietf.org/internet-drafts/draft-gont-6man-slaac-renum-08.txt Status: https://datatracker.ietf.org/doc/draft-gont-6man-slaac-renum/ Htmlized: https://tools.ietf.org/html/draft-gont-6man-slaac-renum-08 Htmlized: https://datatracker.ietf.org/doc/html/draft-gont-6man-slaac-renum Diff: https://www.ietf.org/rfcdiff?url2=draft-gont-6man-slaac-renum-08 Abstract: In renumbering scenarios where an IPv6 prefix suddenly becomes invalid, hosts on the local network will continue using stale prefixes for an unacceptably long period of time, thus resulting in connectivity problems. This document improves the reaction of IPv6 Stateless Address Autoconfiguration to such renumbering scenarios. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat

1 0

IPv4 Flag Day
by Niall O'Reilly 15 May '20

15 May '20

In https://ripe80.ripe.net/archives/chat/88/ 13:23 < luna> https://ipv4flagday.net/ 13:24 < chrbre_AS206228> https://github.com/ipviolations/ipv4flagday/issues Thanks, Luna and Christian, for pointing me at this, which is a fine idea. I’ve added an issue for false alarm when zone apex has no address record of either kind. Niall

4 5

RIPE 80 IPv6 wg session Wilhelms DSL broke, some unanswered questions
by Jetten Raymond 14 May '20

14 May '20

Hello All, Thank you all for watching the IPv6 WG virtually, at the latest minutes of Wilhelms presentation Q&A his dsl connection unfortunately went down, there were still some questions in the buffer, could you Wilhelm comment yet on these ? Any tips to get app developers on board to develop IPv6 enabled apps? It's not uncommon for companies to exclude IPv6 from minimum viable product as its "too hard" Could disabling SLAAC and better DHCPv6 support (eg in mobile devices) help the deployment? It would help with some migrations from IPv4 to IPv6 I think. (Mark Scholten / asking for myself) Rgds, Ray For Internal Use Only

8 8

Re: [ipv6-wg] RIPE 80 IPv6 wg session Wilhelms DSL broke, some unanswered questions
by JORDI PALET MARTINEZ 14 May '20

14 May '20

My view on the 2nd one: I think SLAAC is sufficient! I guess unless Android change their mind and develops/enables DHCPv6, this will not be useful. Regards, Jordi @jordipalet El 14/5/20 13:59, "ipv6-wg en nombre de Jetten Raymond" <ipv6-wg-bounces(a)ripe.net en nombre de raymond.jetten(a)elisa.fi> escribió: Hello All, Thank you all for watching the IPv6 WG virtually, at the latest minutes of Wilhelms presentation Q&A his dsl connection unfortunately went down, there were still some questions in the buffer, could you Wilhelm comment yet on these ? Any tips to get app developers on board to develop IPv6 enabled apps? It’s not uncommon for companies to exclude IPv6 from minimum viable product as its “too hard” Could disabling SLAAC and better DHCPv6 support (eg in mobile devices) help the deployment? It would help with some migrations from IPv4 to IPv6 I think. (Mark Scholten / asking for myself) Rgds, Ray For Internal Use Only ********************************************** 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

RIPE80 IPv6 WG Session
by Jen Linkova 08 May '20

08 May '20

Dear IPv6 Enthusiasts, The agenda for IPv6 WG at RIPE80 has been published: https://ripe80.ripe.net/programme/meeting-plan/ipv6-wg/ The instructions on how to attend the RIPE80 sessions could be found at https://ripe80.ripe.net/attend/how-to-participate/ See you there! -- SY, Jen Linkova aka Furry on behalf of IPv6 WG Chairs.

1 0

RIPE80 Call for Presentations
by Jen Linkova 01 May '20

01 May '20

Dear IPv6 Enthusiasts, As you might have noticed, RIPE80 is going to be a virtual meeting. So IPv6 WG is going to meet on Thu, May 14th, 13:00 - 13:45 CEST (Don't forget to convert to your local timezone). We are looking for talks. COVID-19 does not seem to be a reason good enough to slow down IPv6 deployments. I suspect it might be a reason for accelerate them, actually. So stories about 'IPv6 in the Time of Cholera' (or any other talks about IPv6) are appreciated. Please send your suggestions (the title, short summary, how much time you need) to ipv6-wg-chair(a)ripe.net. Thanks, -- SY, Jen Linkova aka Furry on behalf of IPv6 WG Chairs.

9 11

Fwd: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum
by Fernando Gont 04 Apr '20

04 Apr '20

Hello, folks, v6ops is WGLC'ing one of the documents (https://tools.ietf.org/html/draft-ietf-v6ops-cpe-slaac-renum-01) we have authored to improve the reaction of SLAAC to renumbering events. This document contains recommendations for Customer Edge Routers. For background, you may want to consult: https://tools.ietf.org/html/draft-ietf-v6ops-slaac-renum-01 If you have any comments/feedback, please do let us know. If possible, on the v6ops list (https://www.ietf.org/mailman/listinfo/v6ops) Thanks! Cheers, Fernando -------- Forwarded Message -------- Subject: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum Date: Mon, 30 Mar 2020 15:47:14 +0000 From: Ron Bonica <rbonica=40juniper.net(a)dmarc.ietf.org> To: v6ops(a)ietf.org <v6ops(a)ietf.org> Folks, This message initiates a WG Last Call on draft-ietf-v6ops-cpe-slaac-renum. Please submit comments by April 13, 2020. Fred and Ron Juniper Business Use Only -- Fernando Gont e-mail: fernando(a)gont.com.ar || fgont(a)si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -- Fernando Gont SI6 Networks e-mail: fgont(a)si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

3 3

New on RIPE Labs: What’s the Deal with IPv6 Link-Local Addresses?
by Philip Homburg 11 Mar '20

11 Mar '20

Dear colleagues, Stephen Strowes, Emile Aben and I published a new article on RIPE Labs on how link-local addresses in IPv6, and specifically the '%eth0'-part of link-local addresses, can have an impact on RIPE Atlas measurements. https://labs.ripe.net/Members/philip_homburg/whats-the-deal-with-ipv6-link-… We think this will be an interesting read for network operators and others who are using RIPE Atlas measurement data or are interested in IPv6. Kind regards, Philip Homburg RIPE NCC

2 1

Can ripemtg SSID promotes NAT64 (at least) during RIPE80 ? :)
by Willy Manga 28 Feb '20

28 Feb '20

Hello, I was looking the trends of the last FOSDEM [1] and I recalled discussions before and during RIPE79. I humbly think you could give a try ... 1. https://blogs.cisco.com/getyourbuildon/fosdem-2020-trends-and-analysis -- Willy Manga @ongolaboy https://ongola.blogspot.com/

5 4

IPv6 WG Minutes - RIPE 79
by Jetten Raymond 16 Dec '19

16 Dec '19

Hello all, Please find attached the draft minutes from the IPv6 WG session at RIPE 79. Do let us know if you want any changes made to the minutes. If we haven't heard from you by 20 December, we'll assume all is in order and publish the minutes to the website as they are. Rgds, Ray, Jen, Benedikt For Internal Use Only

1 0

New on RIPE Labs: How to Build and Market IPv6-only Services
by Mirjam Kuehne 04 Dec '19

04 Dec '19

Dear colleagues, For those of you who missed Nico Schotteluis' presentation at RIPE 79, here is his story on how they built and marketed IPv6-only services (including cute penguin drawings :-)): https://labs.ripe.net/Members/nico_schottelius/how-to-build-and-market-ipv6… Kind regards, Mirjam Kühne RIPE NCC

1 0

Its that time of the year...
by Yannis Nikolopoulos 02 Dec '19

02 Dec '19

...when we're starting to deploy yet another IPv6-only technology :) Hello all, as a fairly large ISP (for Greek standards at least), we've been affected by IPv4 exhaustion for quite some time now. A few years back we gave LW4o6 a go, as documented here https://ripe76.ripe.net/presentations/11-lw4o6-deployment-as6799.pdf . In the end, it did not work out very well. Quoting myself (from v6ops mailing list), the reasons behind that were: "In no particular order: 1. CPE (almost OK after ~2 years and god knows how many iterations) 2. lwaftr performance (worth noting the the lwaftr is implemented as a VNF 3. vendor's reluctance to continue (much needed) dev/ment because of *lack of interest from other ISPs* " Please take extra note of (3). In any case, being the optimists we are, and having supportive mgmt, we decided (once more) against burying ourselves deeper into CGN. This time we're going with MAP-E (which incidentally was our first choice), mainly because we understand it and our MAP BR vendor does too :) . So, as I already mentioned, we're just about to deploy it commercially. We've tested with 2 CPE vendors sucessfully and we're just ironing out some provisioning details before launching. Deployment will be gradual of course and very very cautious. Unofficially, we are aware of a couple of similar trials from other ISPs and we'd love to hear about people who have already deployed such technologies (IPv6-only with IPv4aas) or are thinking about doing so. After all, that is exactly what this WG is about :) thanks for reading, Yannis

3 3

Re: [ipv6-wg] Its that time of the year...
by Jan Zorz - Go6 02 Dec '19

02 Dec '19

On 01/12/2019 20:57, Ole Troan wrote: >> No matter how hard you try, at the end of the day LW4o6 is still >> stateful mechanism. > > Just make sure there are no misunderstandings. MAP-E and LW46 both > have the same NAT placement (at the CPE). A MAP-E implementation can > implement LW46 by supporting a MAP rule per subscriber. So it’s more > correct to say that LW46 has per-user configured state, and that > MAP-E can aggregate this configured state into a few rules covering > the whole domain. Both are stateless, in contrast to a NAT that has > state per session. Ya, you are right. Got confused for a millisecond with dslight ;) Too many things going on right now. My bad. As far as I remember - LW4o6 is useful in cases where you don't have one huge IPv4 block of addresses to assign to the transition mechanism and/or where you want to dynamically assign additional ports to the CPE if it runs out of it. If none of this is a requirement, then MAP-E/T should be the way to go. Do we have any experiments/deployments of 464XLAT in fixed networks? CLAT in CPE and NAT64 in the core? Cheers, Jan

1 0

Disband IPv6 WG
by Jens Link 29 Nov '19

29 Nov '19

Hi, after now almost 12 years using, working and teaching[1] IPv6 I've come to the conclusion that IPv6 is a mistake and will not work. Therefore the RIPE IPv6 WG should be disbanded and replaced with a new WG that MUST investigate all possible solutions to artificially prolong the live of IPv4 till the day a new successor for IPv4 is created and implemented! Some great ideas[2] are already proposed, some of them already implemented: - Use of NAT - Use of the first Class-A network 0.0.0.0[3] - Use of parts of localhost Class-A network 127.0.0.0 - Use of (parts) of Class-D address space (multicast) - Use of Class-E address space (future use) - Using part of the UDP / TCP port range as extension for the address. Some of the reserved address spaces could also be used. E.g. nobody is using 192.0.2.0/24 for documentation anyway. It should also be investigated to take back legacy IPv4 resources, although the "owners" of these resources might already selling them on the open market. It MUST also be considered not filtering on Class-C[4] bounderies but going for something smaller like /26 or /27 in the global routing table. Also new Class Designations for these prefixes MUST be created. The new successor to IPv4 should not make the same mistakes as IPv6. - IT MUST have NAT - It MUST have Classes - IT MUST have DHCP - It MUST have ARP - It should be possible to drop ICMP the same impact as in IPv4. Many experts I talked to over the years told me that blocking ICMP has no negative impacts. - It MUST only have numbers and dots "." - There should be absolutly no reasons to use "[ ]" in URLs Probably the best way to proceed is to just add one or two octets to the address. One of the reasons for the above is that there are so is so many good documentation already written about IPv4! And people already know about IPv4! Why waste this knowledge and experience? There is also plenty of good software out there that can't work with IPv6[5] Change is bad! People don't want to learn! IPv4! MUST! NOT! DIE! Jens [1] at least trying to teach, as one can see from the great number of people actually using IPv6 with little success [2] https://netdevconf.info/0x13/session.html?talk-ipv4-unicast-expansions [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… [4] a Class-C network is the equivalent of an /24. I was told by experts that the definition of some bit set in the first octet of an IPv4 address is complete and utter nonsense [5] like a 20 year old shell script that is so important for $university that it would be hard for them to implement IPv6!

33 64

Fwd: SLAAC renum: Problem Statement & Operational workarounds
by Fernando Gont 23 Oct '19

23 Oct '19

Folks, Your input would be very welcome. Preferably on the v6ops wg mailing-list (https://www.ietf.org/mailman/listinfo/v6ops), but also on this list or multicast to us (authors). Thanks! -------- Forwarded Message -------- Subject: SLAAC renum: Problem Statement & Operational workarounds Date: Wed, 23 Oct 2019 03:51:32 -0500 From: Fernando Gont <fgont(a)si6networks.com> To: IPv6 Operations <v6ops(a)ietf.org> Folks, Earlier this year there was a lot of discussion about slaac renumbering problems. Our original I-D covered everything from the problem statement to proposed protocol updates and operational workarounds. Based on the comments received while discussing this topic on this list and other forums, and in order to keep the discussion better focused on specific aspects of the problem, we have posted a v6ops-targetted document that focuses on: * The problem statement * Discussion of operational workarounds, and associated constraints The document is available at: https://tools.ietf.org/html/draft-gont-v6ops-slaac-renum We'd like to hear from the wg whether we have missed anything, whether the document is useful to the community, etc. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont(a)si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

1 0

Have we failed as IPv6 Working Group?
by Wolfgang Zenker 11 Oct '19

11 Oct '19

Hi, the description of the working group says: "The IPv6 Working Group is for anyone with an interest in the next generation Internet Protocol. The activities of the WG include education and outreach, sharing deployment experiences and discussing and fixing operational issues." I know we do all of this at RIPE Meetings and maybe other times as well, but still ... ... the default network at RIPE Meetings is the dual-stack network, with the IPv6-only (NAT64) network as a barely used extra which is "supported on a best effort basis". With the effect that almost no-one except a few "ipv6 zealots" uses it. This tells me that a significant part of the RIPE community does not only consider this setup "not production ready" but expects an amount of breakage so huge that it's not acceptable to try it out and see what would actually break (while still offering a dual-stack network as a fallback, of course). ... the results of the RIPE NCC survey published today lists the scarcity of IPv4 addresses as one of the largest challenges facing the participants in the survey. At the same time, about one quarter of participants has no plans for deploying IPv6, with the most common reason given as "there is no business requirement for IPv6". This tells me that a significant part of the RIPE community does not view a migration to IPv6 as a useful way to deal with the shortage of available IPv4 address space. These two examples both concern the RIPE community, a group of people that are highly interested and knowledgeable in the field of internet operations. Now think about what the situation might look like at your friendly neighbourhood IT shop or network department. I maybe wouldn't call the IPv6 WG "failed", but it clearly still has a long way to go until we can claim "mission accomplished". Wolfgang

26 68

Re: [ipv6-wg] Have we failed as IPv6 Working Group?
by Geert Jan de Groot 09 Oct '19

09 Oct '19

Folks, I've been out of the ISP business for a while now, but may I make some observations: Many of the major content providers are IPv6-enabled. The question is for end users, how to use IPv6 to access these services. In the Netherlands, there is no mobile operator providing IPv6 connectivity. None! I cannot get IPv6 on my mobile connection! Also, in the Netherlands, the one Internet-to-home provider providing dual-stack IPv6 (w/o NAT mess) is being assimilated by it's parent who, after twenty-five years, is still technologically behind and can't deliver IPv6 themselves. The mitigation to get IPv6 access for endusers who can't get IPv6 from their provider (sixxs.net) closed doors two year ago. I am not aware of any VPN-provider offering IPv6 service to allow endusers to augment the limited offering from their service provider. It isn't a matter of "switch to a provider who has", for endusers, there is *nothing to choose from*. We can do all kinds of exercises (IPv6-only event networks, eat-your-own-dogfood exercises), but there must be reasons for having a business case for not providing IPv6 to end users. Perhaps they are non-technical, but reasons they are; if there would be a business case, people would be doing it. And perhaps these (non-technical?) reasons should be something the WG can look at. A fair number of members of this WG are related to the ISP industry and perhaps can shine some light as to the "why don't you" for access providers? Geert Jan

4 3

[official] What Shall This WG Do
by Jen Linkova 08 Oct '19

08 Oct '19

Hello, dear IPv[0-9] enthusiasts, supporters and zealots, As a co-chair I'm excited to see some discussion happening here, especially after the list has been quiet for a while. I'm less excited to see that some people have started giving up hope and telling the rest of use we shall give up to.. By a lucky coincidence we have 10 mins open-mic slot during IPv6 WG session in Rotterdam to discuss what the WG is doing and what we, as a community, want it to do (however after reading all those threads I'm afraid 10 mins might not be enough). What I'd like to ask you meantime is to think what the priorities and goals are. Get IPv6 adoption to 100%? (Is it realistic? Shall we target to 100%?) Convince everyone that IPv6 is good and IPv4 shall be turned off? Provide a venue for those who are interested to discuss the topic and share the experience (including negative one? Produce documents (or recommendations?) Educate people? What should be considered as success, what is the failure and what is just a roadblock? The current WG charter is available on https://www.ripe.net/participate/ripe/wg/ipv6 Please read it and let's discuss if anything should be changed there. -- SY, Jen Linkova aka Furry

4 3

Re: [ipv6-wg] Have we failed as IPv6 Working Group?
by mailinglists＠high5.alioth.uberspace.de 08 Oct '19

08 Oct '19

On 19-10-07 20:05:18, Bjoern Buerger wrote: > * Martin Schr??der (martin(a)oneiros.de) [191007 19:13]: > > Am Mo., 7. Okt. 2019 um 18:04 Uhr schrieb Dave Taht <dave.taht(a)gmail.com>: > > > If I can get *one* person in this working group to go down to their > > > local coffee shop and make ipv6 work by whatever means necessary (and > > > > Please start by eating your own dog food and make future RIPE meetings > > IPv6 only. > > +1 > It is possible to do do v6 only networks; troopers.de had a rather nice v6 only net and as a half pentest conference included finding non working services as targets for the CTF. Maybe you should just encourage power users to adopt v6 and annoy the companies breaking it. And maybe enno's name was mentioned somewhere there too... ;) Greets J

1 0

Re: [ipv6-wg] Have we failed as IPv6 Working Group?
by Dave Taht 08 Oct '19

08 Oct '19

Michel Py <michel(a)arneill-py.sacramento.ca.us> writes: > Hi Carlos, > >> Carlos Friaças wrote : >> We have to acknowledge "IPv6 zealots" are real. >> Disclaimer: i think i was part of that group some years ago. > > Indeed, and so was I. WAS. As was I. Straws that broke my back finally were not being able to get a static IPv6 address out of comcast, my hurricane tunnel getting blocked by netflix, the still-huge prefix sub-distribution problem. The idea of dynamic 2 week prefixes in part of the world prone to earthquakes doesn't work for me... and my email over ipv6 is perpetually getting blocked. spamhaus blocked multiple attempts to get dave(a)taht.net (fully ipv6 enabled) to send mail ti this list. And I sat on it for an hour after clearing it, in the hope the block would clear. It didn't. Getting off email blocklists isn't a problem users can handle... and spamhaus has no means of interacting with me. I *really* wanted email right to my servers in my office to just work, over ipv6. Everywhere I've been lately (nicaragua, portugal) has switched to whatsapp. Damn it, I wanted ipv6 to roll out faster than it has. I'm in a half dozen RFCs, worked in IETF homenet, founded the cerowrt project with an explicit goal of making ipv6 more deployable (as we did!), *by actually implementing and distributing* more code based on the standards, and I plan to keep working on making ipv6 better, but that said, we need more running code, still, which only then can get into a deployment, and nobody's funding that. Nobody's implemented much of ietf homenet. there's no code to enable prefix distribution on android. those are my top two ipv6 bullet items. more universal SADR would help. Tunnels of all types "just working" would be good too. Perhaps with the chinese government mandating more ipv6, more open source code, at least, will get funded and written. Maybe not of the freedom and privacy enhancing stuff, though. > > >> But Mr.Rey's reference about IPv6 deployment rates also makes a good point! > > Nobody cares about deployment rates. What good does it do, if people don't use it ? > This is more realistic : https://www.google.com/intl/en/ipv6/statistics.html > During the week, we are below 25%. One entertaining thing I've been up to is checking the state of multiple kinds of deployment in the coffee shops of the world with a string of simple tests anyone can do (after we package them up better) https://lists.bufferbloat.net/pipermail/bloat/2019-September/009334.html So far thats: Bufferbloat: 95% (starbucks is doing the right thing here, yea!) IPv6: 0% DNSSEC: 0%. "coffee shop testing" offers y'all the opportunity to go "fix it" by leaping over the counter, and/or to get a deeper grip on the real deployment problems we have with middleboxes along the edge. Sometimes leads to free coffee, too! Please have more meetings in coffee shops, not conventions! Does anybody here, know what the heck the 5G people plan to do with IPv6? and new places like starlink and oneweb and the like? I really hope the 5G folk are going to get ipv6 prefix distribution and SADR right, but have no data. > >> We also have to acknowledge "IPv4 zealots" are real. > > And they are the ones with the money. The lobbyists. The connections. The banana peels. The 75% market share. > The IPv4 zealots have not always been there; they have been created as a reaction to the nonsense of the IPv6 zealots. > IPv6 replacing IPv4 is a delusion. I should make clear I'm not a zealot of any sort on the ipv4 vs ipv6 front. (I freely confess to being zealous about fq_codel... but if you deployed it and looked at the data, I figure more would become one also! :)) I came to the reluctant conclusion last year that dual stack is going to be ~forever, that ipv6 was platauing in multiple ways and we needed to kick it harder, that the rollout stats vs actual usage were hopelessly overoptimistic... and went poking at what we could do to ALSO make ipv4 better as a third way out and have been plunking away it ever since. One thought was: Since there was demand for more IPv4, perhaps that would also fuel more updates to ipv6, as both require middlebox updates... As for money to make middleboxes better in *any* way, don't make me laugh. During the cerowrt project we approached everybody making money from the internet and multiple non-profits and got nowhere. I spent my own fortune on it, and got a lot of volunteers onboard, especially in the openwrt universe... and made things better, but I got nothing left. We need a new kame-like project to jointly handle the cracks in the ipv6 network architecture, standards and code, at the very least. The costs of "mo ipv4" are trivial in comparison. > 3 months ago, I turned DECNET off on my network. It was actually not > even an IT/network decision; customer decided they were done with a > product, and we de-commissioned the tools with DECNET. Business > decision. We run OS/2 Warp, MS-DOS, Windows 95, HPUX, Solaris, Windows > 2000, and I probably forget some. Please note the ipv4 extensions stuff won't work with most that "legacy" ipv4 stuff. It can, however, enable new applications and services to exist. Most of the IOT and SDN stacks already do work. Most don't have decent ipv6 support due to resource constraints. Perversely I kind of like the idea of a portion of the internet immune from legacy windows worms and viruses.... > > In 20 years, I will still need IPv4. And it seems possible we can make more. > And I have enough IPv4 on my hands for the foreseeable future. I bought some recently, just in case. > > > I encourage the WG group to read this : > https://www.internetgovernance.org/2019/02/20/report-on-ipv6-get-ready-for-… > And the full text : > https://www.internetgovernance.org/wp-content/uploads/IPv6-Migration-Study-… > Serious work, paid by ICANN. We cited that work in our presos on this subject as that was also key on gilmore, paul wouters and myself to start looking hard at what it would take to make ipv4 better in multiple ways. Please look it over!? The ipv4 unicast extensions project is one outgrowth of that: A string of trivial patches to a couple OSes and routing daemons and we're well on our way to being able to add 420m new addresses to the internet, within a 10 year time horizon. Politically... oh, lawd. I'm focusing on technical feasibility only at the moment. If you want some details about that, see the WIP here: https://github.com/dtaht/unicast-extensions/tree/master/rfcs I'd like lots more folk to review this before we punt it up to iana and the ietf, the RIRs and so on, and more to fiddle with 240/4 and 0/8, at least. Pay special attention to section 7.1. There's more than just this to make ipv4 better, possible. Taking flack on just this much is no fun, but can we get more folk thinking out of this box in general? We certainly aren't proposing that ipv6 wg's *disband* but if more folk would focus on making the code work and implementing more of the standards that exist, AND looking at deployment problems with an open mind and willingness to get in there and fix them, that would be a goodness. -- Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740

24 53

ipv6 over 5G?
by Dave Taht 07 Oct '19

07 Oct '19

Earlier in this thread I'd asked: "How is ipv6 going to work over 5G"? and got no replies. Anyone? All I know is the 3gpp working groups have been participating in ietf a bit, and we're "in a race" to 5G, currently controversial due to huewei being so far ahead on it than everyone else and controlled by the chinese PLA. My primary interest is in the fixed line deployments of the wireless stuff that can only work outdoors - not the phones. I know of multiple providers planning to replace dsl with 5G but have no idea how they plan to do it. I figure CGNAT factors in a lot. Are people going to get a /48? Static or dynamic? How will ipv4 be delivered? Can they buy a real IPv4 address for their business? Any pointers to public documents on how it's intended to work with ipv6 would be welcomed, and if this is a question covered by this group before, please steer me in the right directions. thx. -- Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740

2 1

Re: [ipv6-wg] Have we failed as IPv6 Working Group?
by Dave Taht 07 Oct '19

07 Oct '19

On Mon, Oct 7, 2019 at 9:23 AM <bob.sleigh(a)bt.com> wrote: > > Congratulations on your contribution to success Dave! > > Regards > > Bob > > Sent from my local coffee shop - using my EE Mobile over native IPv6 Yea! thank you! That cheers me up a lot. I hadn't found a single coffee shop yet that had it. But my request was that someone go to their local coffee shop and *make* it work when it didn't already. Care to go for 2/2? Test for bufferbloat via dslreports.com and/or flent's rrul test? > -----Original Message----- > From: ipv6-wg <ipv6-wg-bounces(a)ripe.net> On Behalf Of Dave Taht > Sent: 07 October 2019 17:04 > To: Bjoern Buerger <b.buerger(a)penguin.de> > Cc: ipv6-wg(a)ripe.net IPv6 <ipv6-wg(a)ripe.net> > Subject: Re: [ipv6-wg] Have we failed as IPv6 Working Group? > > If I can get *one* person in this working group to go down to their local coffee shop and make ipv6 work by whatever means necessary (and also fix their bufferbloat) - I'll consider my participation in this thread a success. > -- Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740

2 2

Re: [ipv6-wg] Have we failed as IPv6 Working Group?
by Lee Howard 05 Oct '19

05 Oct '19

On 10/5/19 12:06 PM, Dave Taht wrote: > Lee Howard <lee(a)asgard.org> writes: > > >> IPv6 deployment in your network means cutting your NAT expense in >> half. More, as more sites deploy. > There's no fungable or measureable "NAT expense". NAT generally saves > money. Look at the container market for one recent example. If you have a dedicated box or service card for NAT, you have a specific NAT expense. If you can buy a smaller box for half the cost, you've saved a specific amount of money. I know of mobile carriers who NATted every Internet connection in IPv4, and have halved their capital expense on NAT. >> IPv6 deployment in your network might mean you can sell some of your >> IPv4 addresses, a clever way I've seen to fund the transition. > That I agree with. But I see no sign anyone is actually doing that. It's > saner to horde at the moment. I've had inquiries along these lines, and written proposals. >> IPv6 deployment on your web site means improving your page load time, >> and therefore SEO, and therefore revenue. At NANOG I showed quotes >> that IPv6 increases revenue by 0.2%-7%.[1] > BS. Happy eyeballs costs time. Here's my assessment: https://www.retevia.net/why-is-ipv6-faster/ >> The cost to deploy IPv6 is not high: it's mostly labor, and people who > BS. It needs to be implemented first in a deployable state. "Deployable"? It's been deployed by the millions. Everyone who's done it says it was mostly labor. >> complain that there's no training are ignoring the hundreds of >> tutorials, books, articles, videos, and web sites available to them >> for free, not to mention the thousands of friendly engineers. >> >> To everyone who sees a high cost, I ask whether you know the value of >> NAT reduction and web site speed (and avoiding buying addresses, or > I note that port exaustion is a real thing on ipv4 networks today that > more should measure. In one recent set of "coffee shop tests", I had an > over 30% initial syn failure rate. I don't know why (we were also > testing ecn) at the moment, but that was a shocking number. > > ipv4 dns with udp was already using up a lot of udp port space. > with quic eating up a lot of udp more, I'm not happy. > > JUST deploying dns over IPv6 as I did Interesting! > >> selling addresses), in $LOCAL_CURRENCY, so you can evaluate every >> obstacle you might encounter. For instance, "Our web conferencing >> doesn't support IPv6, and it'll cost us $9,000 a year to change. But >> IPv6 will save us $30,000." The decision is easy. > That last number is pure BS. It's not a single cost. It's that last > dangling set of apps that can't be converted to ipv6 that's the infinite > cost. I'm not sure what you're calling "BS." Obviously $30,000 was a made-up number for the example. I don't know what "dangling set of apps" you mean that can't be converted, especially in the context of "How much would it cost to add IPv6 support?" >> In another message on this thread I noted that small ISPs are squeezed >> between CPE and IPv4 purchases. They can't get CPE that supports IPv6, >> or that supports MAP or 464xlat, because they don't buy enough, so >> they have to pay to buy addresses. > They can't get cheap CPE that has those features. ALL that code runs > great in openwrt. > > And ipv4 addresses are needed until ipv6 hits 100% deployment. Fewer IPv4 addresses are needed in the context of MAP or 464xlat. >> That's easily solved by collective >> action: 100 small ISPs can get the features they want (at a better >> discount) than one acting alone. > Great. Is there an ISP association trying to do that already? Not that I know of. If there's interest, I'll support, maybe organize. Lee

1 0

Re: [ipv6-wg] Have we failed as IPv6 Working Group?
by Lee Howard 05 Oct '19

05 Oct '19

On 10/5/19 11:53 AM, Dave Taht wrote: > Lee Howard <lee(a)asgard.org> writes: > >> On 10/4/19 4:55 PM, Dave Taht wrote: >>> not being able to get a >>> static IPv6 address out of comcast, my hurricane tunnel getting blocked >>> by netflix, the still-huge prefix sub-distribution problem. The idea of >>> dynamic 2 week prefixes in part of the world prone to earthquakes >>> doesn't work for me... >> I can think of several programmatic ways to deal with that. > ... > > for real use a static ipv6/48 to distribute is needed. Dynamic ipv6 > assignments are fine if you are doing trivial stuff but if ipv6 is ever > to even start to supplant ipv4 it's got to become more static. Or more resilient to renumbering. I didn't mean to suggest that you as a user should have to code your home network. I meant that we (maybe IETF) have not done well at handling the case of "I received a new prefix, and I am the edge router; I need to tell everything else what changed." Thus kicking off RAs, DHCPv6 updates, dDNS updates, and a firewall that understands dynamic prefixing. >> I was thinking about some Hackathon projects to add IPv6 capability to >> open source projects. Seems to me the hardest part is making sure >> there's an adequate test environment. > Hackathons ARE useful tools for getting a short burst of focused work > out of people sharing the same space and time, but too many are thinking > hackathons alone will solve more detailed design, coding and iteration > problems; it's one of those ideas trivializing the costs of "Real > Programming(tm)" that really bugs me nowadays. > > I could share here the detailed project management stuff that went into > cerowrt's run (3 years), or the outline of work we did for > make-wifi-fast - which we've now been at for over 5 years now - 3+ to > get fq_codel to work right on wifi, 2 to rework the API to work for more > devices, and a pointer to the latest work which has been going for 3+ > months now - and for all that we've only accomplished about 1/10th what > we wanted to do, and only on 4 chipsets (most recently intel's ax200 > chips) out of the hundreds. This might make for an interesting WG discussion, getting actual work organized and done. >>>>> But Mr.Rey's reference about IPv6 deployment rates also makes a good point! >>>> Nobody cares about deployment rates. What good does it do, if people don't use it ? >>>> This is more realistic : https://www.google.com/intl/en/ipv6/statistics.html >>>> During the week, we are below 25%. >> (Replying to an item upthread) >> >> APNIC's statistics show that in almost every network that has IPv6, it >> is almost always used. > I pointed to coffee shops as one counter example. If they don't have IPv6, they're not using it. > To the lack of > DHCPv6-PD on android (and I think, IOS) for tethering as another. Based on discussions at IETF, I guess Android is expecting to get multiple IPv6 addresses and reassign as needed. Don't know about IOS. >> Another thought I've had: >> >> One of the reasons small ISPs can't deploy IPv6 is that they don't >> control the features in the CPE, because they don't buy enough. >> >> I know a couple CPE vendors who would be happy to provide a specific >> feature set for a guaranteed purchase of a couple thousand units a >> month. This sounds like a good business to me: if a bunch of small >> ISPs each contract for a specific number of units, but require >> RIPE-554, RFC7084, and RFC8085, we could both get the needed features, >> and get a larger volume discount than they get now. > Yes, the smaller ISPs should join together in a buying > club like that. Tried to get that going in NZ once. Failed. > > tried harder to make the aftermarket do the right thing - the eeros and > google wifi's of the world are doing ok, the bottom part of the market > just copy/pastes whatever's in openwrt at that moment, slaps a label > on it and ships it. So we focused on making the openwrt base as good > as possible. Might be another part of "What the WG should do" discussion. >> Saving $1 per CPE is better than spending $20 for an IPv4 address for >> every new user. Please confirm my math. :) > I always thought that ISPs would invest in their CPE far more than they > have. Free.fr being a shining example! ISPs get paid for modem rentals > and have customer support costs that could be reduced - that should have > been a great ongoing funding source and motivation, alone. > > but I know a few vendors, like evenroute, doing bufferbloat AND ipv6 > right, that have totally failed to crack ISP market thus far. > > and for no reason I can think of, the rental folk don't push out > new hardware OR new software to their users - I think charter made > an effort to get docsis 3.1 stuff out there and retire all the docsis > 2.0 gear in place, but not comcast. > > Secondly none of those ipv6 standards help when you still really need a > real IPv4 address, so yer still out the $20, IF you can buy the /24s you > need. And there's more ipv6 RFCs left without running, integrated code, > to support them. In my experience, accountants run the CPE purchasing, and saving 5¢ per unit is worth more to them than avoiding 10% of them driving $30 support calls. Same with rentals: why replace when the cost is already completely written off? There are some good reasons (like technical debt dragging on forward competitiveness) to replace. It may be the case that not everyone needs a unique IPv4 address. Several broadband ISPs have deployed DS-Lite, for example. I don't know the business model; do they charge for unique IPv4 addresses when needed? That's sort of back to my other point of aligning expenses and revenues. >> You just mentioned your un-upgradable "OS/2 Warp, MS-DOS, Windows 95, >> HPUX, Solaris, Windows 2000," and now you say it's easy to upgrade. > I didn't say it was "easy to upgrade" in the context of this legacy > gear, I said it was easy to "add" 420m addresses. 240/4 is almost fully > enabled in every OS except windows, for example. Fixed the last bug > in it for linux and openwrt last december. Deploying. 0/8 now. What's the relative level of support for unicast 240/4 and IPv6? > > Yea, people keep missing on this point. IPv6 is not globally reachable > either. To try and clarify: A new IOT device trying to backhaul its > data to 240.0.0.1 doesn't need to have a windows OS also trying to get to > that same address. Is that clearer? A new application can try to use > new IPv4 addresses. Do you mean 240/4 for private connectivity, or 240/4 publicly routed and it's fine for some applications if it's unreachable? Do all routers etc support it? Lee

1 0

Disband IPv6 WG
by Blake 05 Oct '19

05 Oct '19

As the OP's goal seems to be XKCD standards compliance(1), perhaps it's time to revive IPv10? https://tools.ietf.org/html/draft-omar-ipv10-11 After all, it took Edison two decades to admit DC power distribution couldn't work, & NYC only had to wait a century more until they could decommission their commercial DC electrical power distribution network... ( https://en.wikipedia.org/wiki/War_of_the_currents ) -Blake 1) https://xkcd.com/927/

2 1

Re: [ipv6-wg] IPv6 WG co-chair selection
by Erik Bais 03 Oct '19

03 Oct '19

Hi Raymond, You have my support for another round. Erik Bais From: ipv6-wg <ipv6-wg-bounces(a)ripe.net> on behalf of "raymond.jetten(a)elisa.fi" <raymond.jetten(a)elisa.fi> Date: Friday 13 September 2019 at 12:04 To: RIPE IPv6 WG <ipv6-wg(a)ripe.net> Cc: "ipv6-wg-chairs(a)ripe.net" <ipv6-wg-chairs(a)ripe.net> Subject: [ipv6-wg] IPv6 WG co-chair selection Hello again, Apologies for the previously incomplete and spelling mistakes email. I hope below is a better version : -- Hello All, Its almost 3 years ago that I started as a IPv6-WG co-chair, so as per our current policy it's time to step down. However, I’m very willing to stand for re-selection, and serve another term as IPv6 WG co-chair, which I hope you all find a good idea. The full process is described here: https://www.ripe.net/participate/ripe/wg/ipv6/ipv6-wg-chair-selection-proce… See you all in Rotterdam! Rgds, Ray

2 1

Re: [ipv6-wg] Disband IPv6 WG
by Jens Link 03 Oct '19

03 Oct '19

Uros Gaber <uros(a)gaber.in> writes: > On 3 Oct 2019, at 14:03, Job Snijders <job(a)instituut.net> wrote: >> Even worse, delivering email over ipv6 to the mail giants is a far >> worse experience than via ipv4. More emails arrive when you >> disable ipv6 on your mail servers. > I would say the same experience as long as the server and supported > services are configured correctly. If you google correctly you'll find many people compiling about google not accepting mail via IPv6. Therefore not many people do SMTP via IPv6. Or if they do they have an extra (v4 only) transport in their outgoing SMTP server. ==> Runing Dualstack is more work. Jens -- ---------------------------------------------------------------------------- | Delbrueckstr. 41 | 12051 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink(a)quux.de | --------------- | ----------------------------------------------------------------------------

1 0

Re: [ipv6-wg] IPv6 WG co-chair selection
by Paul Hoogsteder 03 Oct '19

03 Oct '19

Hello Routing WG members, I support Raymond's re-election. Kind regards, Paul Hoogsteder Meanie AS31019

1 0

Re: [ipv6-wg] IPv6 WG co-chair selection
by Kennedy, James 02 Oct '19

02 Oct '19

+1 support for Ray Regards, James From: ipv6-wg [mailto:ipv6-wg-bounces@ripe.net] On Behalf Of Jetten Raymond Sent: 13 September 2019 12:04 To: RIPE IPv6 WG <ipv6-wg(a)ripe.net> Cc: ipv6-wg-chairs(a)ripe.net Subject: [ipv6-wg] IPv6 WG co-chair selection Hello again, Apologies for the previously incomplete and spelling mistakes email. I hope below is a better version : -- Hello All, Its almost 3 years ago that I started as a IPv6-WG co-chair, so as per our current policy it's time to step down. However, I'm very willing to stand for re-selection, and serve another term as IPv6 WG co-chair, which I hope you all find a good idea. The full process is described here: https://www.ripe.net/participate/ripe/wg/ipv6/ipv6-wg-chair-selection-proce… See you all in Rotterdam! Rgds, Ray

1 0

IPv6 WG co-chair selection
by Jetten Raymond 01 Oct '19

01 Oct '19

Hello again, Apologies for the previously incomplete and spelling mistakes email. I hope below is a better version : -- Hello All, Its almost 3 years ago that I started as a IPv6-WG co-chair, so as per our current policy it's time to step down. However, I'm very willing to stand for re-selection, and serve another term as IPv6 WG co-chair, which I hope you all find a good idea. The full process is described here: https://www.ripe.net/participate/ripe/wg/ipv6/ipv6-wg-chair-selection-proce… See you all in Rotterdam! Rgds, Ray

6 5

IPv6 WG agenda
by Jen Linkova 30 Sep '19

30 Sep '19

Hello, The agenda for IPv6 WG session at RIPE79 has been published: https://ripe79.ripe.net/programme/meeting-plan/ipv6-wg/ See you all in Rotterdam! -- SY, Jen Linkova aka Furry on behalf of IPv6 WG chairs.

1 0

IPv6 WG chair election
by Jetten Raymond 19 Sep '19

19 Sep '19

Hello All, Its almost 3 years ago that I started as a IPv6-WG co-chair, so as per our current policy it's time to step down. However, I'm very willing to stand for re-election, and serve another term as IPv6 WG co-chair, which I hope you all find a good idea. See you all in Rotterdam! Rgds, Ray

14 13

Re: [ipv6-wg] IPv6 WG co-chair selection
by Janos Zsako 18 Sep '19

18 Sep '19

Dear Ray, > Its almost 3 years ago that I started as a IPv6-WG co-chair, I think you did a very good job, thank you. > so as per our current policy it's time to step down. > > However, I'm very willing to stand for re-selection, and serve another term as IPv6 WG co-chair, which I hope you all find a good idea. I am glad to hear this. I strongly support your re-election. Best regards, Janos > Rgds, > Ray

1 0

RIPE 78 Minutes
by Jetten Raymond 14 Sep '19

14 Sep '19

Hello all, The minutes from RIPE 78 are now available: https://www.ripe.net/participate/ripe/wg/ipv6/minutes/ipv6-working-group-mi… Please let us know if you have any comments. Cheers, Jen, Benedikt and Ray

1 0

RIPE 79 IPv6 Working group
by Jetten Raymond 30 Jul '19

30 Jul '19

Hello All, The RIPE 79 meeting will take place will take place in Rotterdam Netherlands from 14-18 October 2019. https://ripe79.ripe.net/ The IPv6 WG session will most likely be on Thursday Morning. (still subject to change). Would you like to present at our WG session, and have a subject that would be of interest on IPv6, or develop IPv6 related RIPE policies, have useful recommendations, or plan other documents that will help the deployment of IPv6 ? We, the IPv6 WG co-chairs, would like to invite you to submit your presentation proposals, including a brief description of the content and the time you would need. Please send them directly to us: ipv6-wg-chairs at ripe.net<https://lists.ripe.net/mailman/listinfo/ipv6-wg> . Once we start to make the final agenda, we will let you know if you are selected or not. Please be aware of the following: Due to potential technical issues, presenters/panelists should be physically present at the RIPE Meeting. RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. All sessions will be recorded and broadcasted, and will be publicly available afterwards, so make sure you own the copyrights of all content. See you in Rotterdam, Jen, Benedikt, Ray

1 0

IPv6 SLAAC renum/problems IETF I-D (Fwd: New Version Notification for draft-gont-v6ops-slaac-renum-00.txt)
by Fernando Gont 07 Jul '19

07 Jul '19

Folks, To make the story short: Based on the recent discussion we had on our IETF I-D draft-gont-6man-slaac-renum, we have posted this new I-D which focuses on discussing the problem, and describing operational mitigations. The document is available at: https://www.ietf.org/internet-drafts/draft-gont-v6ops-slaac-renum-00.txt Comments are welcome. It is being discussed on the IETF v6ops wg mailing-list: https://mailarchive.ietf.org/arch/msg/v6ops/5D2hdpB6QHRm9u-MUj6erQaLZY0 If possible, post your comments on the v6ops wg list. But comments are welcome, whether there, here, or even unicast to us (co-authors) ;-) Thanks! Cheers, Fernando -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-v6ops-slaac-renum-00.txt Date: Sat, 06 Jul 2019 08:59:12 -0700 From: internet-drafts(a)ietf.org To: Fernando Gont <fgont(a)si6networks.com>, Jan Zorz <jan(a)go6.si>, Richard Patterson <richard.patterson(a)sky.uk> A new version of I-D, draft-gont-v6ops-slaac-renum-00.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-v6ops-slaac-renum Revision: 00 Title: Reaction of Stateless Address Autoconfiguration (SLAAC) to Renumbering Events Document date: 2019-07-06 Group: Individual Submission Pages: 14 URL: https://www.ietf.org/internet-drafts/draft-gont-v6ops-slaac-renum-00.txt Status: https://datatracker.ietf.org/doc/draft-gont-v6ops-slaac-renum/ Htmlized: https://tools.ietf.org/html/draft-gont-v6ops-slaac-renum-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-gont-v6ops-slaac-renum Abstract: In scenarios where network configuration information related to IPv6 prefixes becomes invalid without any explicit signaling of that condition (such as when a CPE crashes and reboots without knowledge of the previously-employed prefixes), nodes on the local network will continue using stale prefixes for an unacceptably long period of time, thus resulting in connectivity problems. This document analyzes these problem scenarios, and discusses operational workarounds to improve network robustness. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat

1 0