- ipv6-wg - mailman.ripe.net

IPv6 faster than IPv4 (also with 464XLAT)
by JORDI PALET MARTINEZ 26 Jun '19

26 Jun '19

We already knew that from previous measurements, however the nice thing from this article is that it is analyzing many different providers worldwide: https://teamarin.net/2019/06/25/why-is-ipv6-faster/ Regards, Jordi @jordipalet ********************************************** 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

RIPE NCC Receives Additional /12 IPv6 Allocation from IANA
by Nikolas Pediaditis 07 Jun '19

07 Jun '19

Dear colleagues, On 5 June 2019, the RIPE NCC received the following IPv6 allocation from IANA: 2a10:0000::/12 All allocations of IPv6 unicast address space made by IANA to RIRs are listed here: https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unic… We received our previous /12 allocation (2a00:0000::/12) on 3 October 2006. The conditions under which we qualified for an additional allocation are described in the IANA Policy For Allocation of IPv6 Blocks to RIRs: https://www.icann.org/resources/pages/allocation-ipv6-rirs-2012-02-25-en The RIPE NCC is the first RIR to receive an additional /12 IPv6 block. As today is also the seventh anniversary of World IPv6 Launch Day, we took the opportunity to look at some of the history of IPv6 and how it has been distributed in our service region: https://labs.ripe.net/Members/riccardo_stagni/we-re-running-out-of-ipv6 Kind regards, Nikolas Pediaditis Registration Services & Policy Development Assistant Manager RIPE NCC

6 6

Useful Information / RIPE78
by Thomas Schäfer 17 May '19

17 May '19

Hi, Is it right, that I can use https://ripe78.ripe.net/on-site/tech-info/ipv6-only-network/ or https://ripe78.ripe.net/on-site/tech-info/dns-over-tls-resolvers/ but not both at the same time? Regards, Thomas -- There’s no place like ::1 Thomas Schäfer (Systemverwaltung) Ludwig-Maximilians-Universität Centrum für Informations- und Sprachverarbeitung Oettingenstraße 67 Raum C109 80538 München ☎ +49/89/2180-9706 ℻ +49/89/2180-9701

3 4

IPv6 WG Ripe 77 meeting minutes, your comments please
by Jetten Raymond 07 May '19

07 May '19

Hello All, Here are the minutes form the previous meeting in Amsterdam, if you have any comments on the content of them, please contact us ( ipv6-wg-chairs(a)ripe.net<mailto:ipv6-wg-chairs@ripe.net> ) In a little over 2 weeks we will approve the minutes including the comments at the RIPE78 meeting in Reykjavik. IPv6 Working Group Minutes - RIPE 77 Date: 18 October 2018, 11:00 - 12:30 WG Co-Chairs: Jen Linkova, Benedikt Stockebrand, Raymond Jetten  Scribe: Massimiliano Stucchi   Status: Draft 1. Welcome/Agenda Bashing/Meeting Minutes The presentation is available at https://ripe77.ripe.net/archives/video/2278/ There were no questions or comments. 2. IPv6 Work at IETF (v6ops/6man WGs updated) Jen Linkova, WG Co-Chair The presentation is available at: https://ripe77.ripe.net/archives/video/2279/ Pawel Lunin from Scaleway mentioned that RFC8475 was recently published, and asked for a more detailed explanation from Jen Linkova, one of the authors. Marco Hogewoning from RIPE NCC thanked the presenters and asked to point those interested towards smaller Internet drafts that haven't been adopted by Working Groups. He suggested taking a look at a specific draft on ENUM numbers and said that participants in the room should comment on that. Cyril Malevanov from Selectel spoke against IPv6 on behalf of the operators from St. Petersburg. He said he wanted his voice to be heard, and to state his opinion. Alissa Cooper, IETF Chair, thanked the presenters on behalf of the IETF. She also stated that if there were ideas, people could approach her and other IETF participants to get help. There were no more questions or comments. 3. Clusters in the Expanse: Understanding and Unbiasing IPv6 Hitlists Oliver Gasser, RACI The presentation is available at: https://ripe77.ripe.net/archives/video/2283/ Jen Linkova, Google, said she liked the conclusions because she finds it hard to understand the issue of security by obscurity. The presenter answered that there was a previous paper that compared the reachability of IPv4 against IPv6 and the outcome was that IPv6 addresses are more likely to respond because firewall rules were not set. Randy Bush, IIJ and Archis asked about the IPv6 responsiveness graph in the slides and how it compares to IPv4. The presenter answered that the numbers are in the paper, but couldn't provide any more data as he couldn't remember it in detail. There were no more questions or comments. 4. We Don't Need IPv6 - Update Jens Link The presentation is available at: https://ripe77.ripe.net/archives/video/2285/ Jen Linkova, Google, commented during the presentation that she wouldlike to do the"IPv6 bullshit bingo" if any more references to a paper mentioned during thepresentation will be highlighted. Randy Bush, IIJ, mentioned that they tried turning off IPv4 at the lastIETF,specifically for the IPv6-related Working Groups (6man, v6ops) and it didn'twork out the way they would have liked. They tried NAT64. Hesaid unfortunately there is still work to be done. Jen Linkova said there were bugs in the network, and 75% of the peoplereported they had no problems getting work done in a survey sent later. There were no more questions nor comments. 5. The Art of Running Out of IPv6 Addresses Benedikt Stockebrand The presentation is available at: https://ripe77.ripe.net/archives/video/2287/ Jan Zorz thanked the presenter and seconded the fact that history repeats itself over and over again, and errors keep being repeated. There were no more questions nor comments. --- The minutes are also available online: https://www.ripe.net/participate/ripe/wg/ipv6/minutes/ipv6-working-group-mi… Rgds, IPv6-WG-Chairs: Jen, Benedikt, Ray

1 0

Agenda for the IPv6 Working group at Ripe 78 Reykjavik
by Jetten Raymond 01 May '19

01 May '19

Dear All, We have published the agenda for the IPv6 working group at the Ripe 78 meeting in Reykjavik Iceland Thursday, 23 May 09:00 - 10:30 A. Welcome, Agenda Bashing [5 min] B. IPv6 Reliability Measurements [30 min] Geoff Huston C. Large-Scale Deployment of IPv6-Enabled Wi-Fi Hotspots [30 min] Enno Rey D. Update on ITU SG-20 IPv6 Deployment Plan [5 min] Marco Hogewoning E. Mobile IPv6 BCOP Doc [5 min] Massimiliano Stucchi F. RIPE-690 Follow-up: SLAAC’s Reaction to Renumbering Events - IETF I-D [15 min] Jan Zorz Thursday, 23 May 14:00 - 15:30 This session will be shared with the Routing Working Group Technology Deep Dive on Modern Router Architectures Ignas Bagdonas See you all in Reykjavik ! Rgds, IPv6 wg co-chairs: Jen, Benedikt and Ray

1 0

Update on ITU-T SG 20 activities: Ceased work on Y.IPv6RefModel
by Marco Hogewoning 18 Apr '19

18 Apr '19

Dear colleagues, At the meeting of ITU-T Study Group 20, in Geneva from 9-18 April, it was decided to end the work item to develop a "Reference model of IPv6 subnet addressing plan for Internet of things deployment" (Y.IPv6RefModel). We again would like to thank this working group for its contribution - both in reviewing the draft recommendation and sharing your concern about the technical merits of the proposed model. We would also like to thank our colleagues from ARIN, GSMA, the administrations of the United Kingdom, United States, Canada and Germany, and the Rapporteur and Associate Rapporteur of Question 3/20 for their contributions, advice and ongoing support in resolving this matter. The RIPE NCC of course, remains committed to promoting and supporting the deployment of IPv6, also with regards to those elements of the Internet of Things that deploy the Internet protocol. We hope to provide a more comprehensive report during this working group’s meeting at RIPE 78 in Reykjavik. Greetings from Geneva, Marco Hogewoning Senior External Relations Officer RIPE NCC

2 1

IPv6 Security for IPv4 Engineers
by Fernando Gont 14 Mar '19

14 Mar '19

Folks, It is often argued that IPv4 practices should be forgotten when deploying IPv6, as after all IPv6 is a different protocol! But we think years of IPv4 operational experience should be leveraged as much as possible. So we are publishing IPv6 Security for IPv4 Engineers as a roadmap to IPv6 security that is specifically aimed at IPv4 engineers and operators. Rather than describing IPv6 in an isolated manner, it aims to re-use as much of the existing IPv4 knowledge and experience as possible, by highlighting the security issues that affect both protocols in the same manner, and those that are new or different for the IPv6 protocol suite. Additionally, it discusses the security implications arising from the co-existence of the IPv6 and IPv4 protocols. The document is available at: https://www.internetsociety.org/blog/2019/03/ipv6-security-for-ipv4-enginee… Comments are welcome. And if you think we've missed something or the like, please drop me en email -- the document can always be revised. P.S.: If you haven't taken a look at it (yet), we have also published the "IPv6 Security Frequently Asked Questions (FAQ)" at: https://www.internetsociety.org/blog/2019/02/ipv6-security-faq 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

IPv6 Implementation for an ISP
by Alessandro Valenza 13 Mar '19

13 Mar '19

Hello, this is the first time I write in this mailing list. I have a question for you. I'm working for an ISP that obtained IPv4 (/22) and IPv6 (/29). I would like to use IPv6. Could you suggest me some documents and some manuals useful to implement IPv6, but avoiding problems for our customers? In particular, I would like to avoid compatibility problems with VoIP PBXs, network printers, alarm systems, etc ... In Italy only few ISPs provide IPv6 addresses and we would like to try to reverse this negative trend compared to the rest of Europe. I hope you can help me understanding the advantages and opportunities in investing in the direction of IPv6. Kind regards Alessandro Alessandro Valenza Ufficio TLC Tel: 0571 1738257 Fax: 0571542536 www.enegan.it CONFIDENZIALITÀ Questo messaggio, inclusi gli eventuali allegati, è indirizzato solo ai destinatari e può contenere informazioni riservate e confidenziali. Se avete ricevuto il messaggio senza esserne un destinatario, o un suo rappresentante autorizzato, la presente comunicazione vale come formale divieto di diffusione del contenuto del messaggio.Se avete ricevuto il messaggio per errore, siete pregati di cancellarlo, assieme a tutti gli allegati, dal vostro sistema e di informare immediatamente il mittente.

5 4

SSL VPN Clients
by christian bretterhofer 12 Mar '19

12 Mar '19

Sorry for a little be off topic query. I am checking which VPN solutions are IPv6 compatible outside and inside the tunnel and can so transport with any IPv6/IPv4 connection IPv6/IPv4 internal to then tunnel Maybe somebody made such tests already and can point me to it. What i found so far: Citrix SSL VPN ( seems to have only partial support) https://support.citrix.com/article/CTX233563 https://www.citrix.com/blogs/2010/07/13/are-citrix-products-ipv6-ready/ so IPv6 / IPv6 not yet supported https://support.citrix.com/article/CTX211780 NetScaler Gateway VPN users are not able to resolve IPv4 DNS when their ISP has IPv6 enabled. OpenVPN https://community.openvpn.net/openvpn/wiki/IPv6 No complete example found yet. Wireguard (LINUX only) seems to support it but missing other stuff like hostchecker Cisco SSL VPN https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_sslvpn/configura… IPv6 Support and Limitations for Pulse Connect Secure Features https://docs.pulsesecure.net/WebHelp/Content/PCS/PCS_AdminGuide_8.2/IPv6%20… Microsoft Direct access (win7/win10) and new Always on VPN (Win10 only) https://directaccess.richardhicks.com/2018/02/05/what-is-the-difference-bet… https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/vp… -- --- best regards Christian Bretterhofer

8 8

Re: [ipv6-wg] IPv6 Implementation for an ISP
by JORDI PALET MARTINEZ 11 Mar '19

11 Mar '19

Hi Alessandro, I will suggest to for IPv6-only with IPv4-as-a-Service. I’m right now doing this deployment with 464XLAT for a customer this week, including wired and cellular access. You can find the slides of my last tutorial in the RIPE meeting at: https://ripe77.ripe.net/programme/meeting-plan/tutorials/ I guess there is a video as well, otherwise, I did a similar tutorial (even with hands-on in this case, total 3 hours) in the last APNIC (just two weeks ago) that you can search for. Regards, Jordi De: ipv6-wg <ipv6-wg-bounces(a)ripe.net> en nombre de Alessandro Valenza <a.valenza(a)enegan.it> Fecha: lunes, 11 de marzo de 2019, 17:41 Para: "ipv6-wg(a)ripe.net" <ipv6-wg(a)ripe.net> Asunto: [ipv6-wg] IPv6 Implementation for an ISP Hello, this is the first time I write in this mailing list. I have a question for you. I’m working for an ISP that obtained IPv4 (/22) and IPv6 (/29). I would like to use IPv6. Could you suggest me some documents and some manuals useful to implement IPv6, but avoiding problems for our customers? In particular, I would like to avoid compatibility problems with VoIP PBXs, network printers, alarm systems, etc ... In Italy only few ISPs provide IPv6 addresses and we would like to try to reverse this negative trend compared to the rest of Europe. I hope you can help me understanding the advantages and opportunities in investing in the direction of IPv6. Kind regards Alessandro Alessandro Valenza Ufficio TLC Tel: 0571 1738257 Fax: 0571542536 www.enegan.it CONFIDENZIALITÀ Questo messaggio, inclusi gli eventuali allegati, è indirizzato solo ai destinatari e può contenere informazioni riservate e confidenziali. Se avete ricevuto il messaggio senza esserne un destinatario, o un suo rappresentante autorizzato, la presente comunicazione vale come formale divieto di diffusione del contenuto del messaggio.Se avete ricevuto il messaggio per errore, siete pregati di cancellarlo, assieme a tutti gli allegati, dal vostro sistema e di informare immediatamente il mittente. ********************************************** 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

SLAAC in renumbering events
by Fernando Gont 08 Mar '19

08 Mar '19

Folks, If you follow the 6man working group of the IETF you may have seen a bunch of emails on this topic, on a thread resulting from an IETF Internet-Draft we published with Jan Žorž about "Reaction of Stateless Address Autoconfiguration (SLAAC) to Renumbering Events" (Available at: https://github.com/fgont/draft-slaac-renum/raw/master/draft-gont-6man-slaac… ) Short version of story: There are a number of scenarios where SLAAC hosts may end up using stale configuration information. For example, a typical IPv6 deployment scenario is that in which a CPE router requests an IPv6 prefix to an ISP via DHCPv6-PD, and advertises a sub-prefix of of the leased prefix on the LAN-side, via SLAAC. In such scenarios, if the CPE router crashes and reboots, it may loose all information about the previously-leased prefix. Upon reboot, the CPE router may be leased a new prefix that will result in a new sub-prefix being advertised on the LAN-side of the CPE router. As a result, hosts will normally configure addresses for the newly-advertised prefix, but will normally also keep (and use) the previously-configured (and now stale!) IPv6 addresses, leading to interoperability problems. The RIPE-690 BCOP document had originally tried to address this problem by recommending operators to lease stable IPv6 prefixes to CPE routers. However, for a variety of reasons ISP may not be able (or may not want) to lease stable prefixes, and may instead lease dynamic prefixes. Most of the voices on the 6man wg mailing-list fell into one of the following camps: * "ISPs should be leasing stable prefixes -- if they don't, they are asking for trouble!" * "CPE routers should record leased prefixes on stable storage, such that they can 'deprecate' such prefixes upon restart -- if they don't, they are asking for trouble!" * "No matter whose fault is this (if there is any single party to blame in the first place), we should improve the robustness of IPv6 deployments" Our Internet-Draft tries to improve the current state of affairs via the following improvements: * Allow hosts to gracefully recover from stale network configuration information -- i.e., detect and discard stale network configuration information * Have SLAAC routers employ more appropriate timers, such that information is phased-out in a timelier manner -- unless it is actively refreshed by Router Advertisement messages * Specify the interaction between DHCPv6-PD and SLAAC -- which was rather under-specified * Require CPE routers to store leased prefixes on stable storage, and deprecate stale prefixes (if necessary) upon restart We are looking forward to more input on the document (or any comments on the issue being discussed), particularly from operators. So feel free to send your comments on/off list as you prefer 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

IPv6 Security Frequently Asked Questions (FAQ)
by Fernando Gont 08 Mar '19

08 Mar '19

Folks, The Internet Society has posted the "IPv6 Security Frequently Asked Questions (FAQ)" I authored. The document is available (HTML, and also easy-to-print PDF) at: https://www.internetsociety.org/deploy360/ipv6/security/faq/ If you think there are other questions that should be added, or have comments on the answers, please do let me know -- the document can eventually be revised. 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

New on RIPE Labs: Deploying IPv6 at IBM
by Mirjam Kuehne 25 Feb '19

25 Feb '19

Dear colleagues, In this article, Andy Mindnich describes how IPv6 was introduced inside IBM’s own network over the past few years. As enterprises in general seem to lag behind in adopting IPv6 as compared to ISPs or carriers, this article is aimed at helping those who still need to build a case within their own company. https://labs.ripe.net/Members/andy_mindnich/deploying-ipv6-at-ibm Kind regards, Mirjam Kühne RIPE NCC

1 0

A common problem with SLAAC in "renumbering" scenarios
by Fernando Gont 31 Jan '19

31 Jan '19

Folks, We have posted a new I-D discussing a problem that can arise in typical deployment scenarios where the CPE obtains a prefix via DHCPv6-PD and advertises a prefix on the LAN side. We also propose a solution to the aforementioned problem. Our draft is available at: https://tools.ietf.org/html/draft-gont-6man-slaac-renum The Abstract is: A very common IPv6 deployment scenario is that in which a CPE employs DHCPv6 Prefix Delegation to obtain an IPv6 prefix, and at least one prefix from within the leased prefix is advertised on a local network via SLAAC. In scenarios where e.g. the CPE crashes and reboots, nodes on the local network continue using outdated prefixes which result in connectivity problems. This document analyzes this problem scenario, and proposes workarounds. Any comments will be welcome. 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

IPv6 Working Group presentations for RIPE78
by Jetten Raymond 16 Jan '19

16 Jan '19

Hello All, The RIPE 78 meeting will take place will take place in Reykjavik Iceland from 20-24 May 2019. https://ripe78.ripe.net/ The IPv6 WG session will most likely be on Thursday after lunch. (still subject to change). Would you like to present at our WG session, and have a subject that would be of interest on 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 Reykjavik, Jen, Benedikt, Ray

1 0

New on RIPE Labs: Answering IPv6 Misconceptions
by Mirjam Kuehne 21 Dec '18

21 Dec '18

Dear colleagues, Please read these two new RIPE Labs articles by Jen Linkova where she responds to some common IPv6 misconceptions that are used as reasons for not deploying IPv6: https://labs.ripe.net/Members/jen_linkova/ipv6-misconceptions-it2019s-fake-… https://labs.ripe.net/Members/jen_linkova/ipv6-misconceptions-it2019s-fake-… Kind regards, Mirjam Kühne RIPE NCC

1 0

Report from ITU Study Group 20 meeting 3-13 December 2018 in Wuxi, China
by Marco Hogewoning 14 Dec '18

14 Dec '18

Dear colleagues, The meeting of ITU Study Group 20 in Wuxi, China, just finished and I’d like to give you a brief report on the discussions of the work on a draft Recommendation on IPv6 addressing. This meeting was the group's first face-to-face meeting since our discussion of the draft Recommendation at RIPE 77 in May 2018 and the July 2018 draft review deadline. The RIPE community's comments were brought to the meeting as a Liaison Statement. Several other parties also submitted their own Contributions, including the RIPE NCC in its role as an ITU Sector Member. The proposal in our Contribution, with reference to earlier discussions and your review, was to discontinue this particular Work Item. The United States Government and ARIN made Contributions along similar lines, seeking to stop the work developing this particular Recommendation. This position was also supported by the United Kingdom, Canada, Germany and several sector members. I’d like to highlight that both in their Contribution and interventions, the US expressed their gratitude to the RIPE community for their extensive review and feedback on the draft Recommendation. The main author of the draft submitted a Contribution with their account of our discussions at RIPE 77 and the review process, as well as a joint Contribution with the Beijing University for Post and Telecommunications providing a case study of an IPv6 address plan. Having taken all of these contributions and interventions into consideration, the focus of the meeting discussion was on whether or not the work should continue. Unfortunately, the RIPE community’s feedback was only taken into consideration as a high-level conclusion that the current text does not meet the technical standards expected, and the actual text of the draft was not reviewed or revised during this meeting. Unable to reach consensus, the question of whether the work should continue was deferred upwards to the meeting of the Working Party and finally to the closing plenary. During the closing plenary, the Chairman of Study Group 20 proposed continuing the work for at least one more meeting on the premise that the draft’s main author would come back with a Contribution addressing the concerns raised with the current draft. He emphasised that the work item would be dropped unless there were contributions and agreement to advance the text at the next meeting. The RIPE NCC accepted the Chairman’s proposal as a constructive way forward. We look forward to the contributions at the next meeting with the expectation that they will address the concerns raised during your review. We would like to thank you again for the constructive comments raised during the review process. We would also like thank the Question’s rapporteur, associate rapporteur and the Study Group’s management team for all their time and assistance, and of course all the member states and sector members that participated in this discussion. The next meeting of Study Group 20 is scheduled to take place in mid-April, in Geneva, Switzerland. Regards, Marco Hogewoning RIPE NCC

5 7

Re: [ipv6-wg] [cooperation-wg] Fwd: Report on ITU Study Group 20 meeting 3-13 December 2018
by Jim Reid 14 Dec '18

14 Dec '18

> On 14 Dec 2018, at 02:44, Marco Hogewoning <marcoh(a)ripe.net> wrote: > > Please find below a report on the meeting of ITU Study Group 20, that I have just shared with the IPv6 Working Group. Marco, as a fellow traveller on the SG20 bus, I thank you for this summary and all the hard work you did in Wuxi and in the preparations for that meeting. You did an excellent job and were a great ambassador for both RIPE and the NCC. You represented our interests very effectively. I appreciate that and hope everyone else here does too.

2 1

IPv6 transition mechanisms used around the world
by Yannis Nikolopoulos 30 Nov '18

30 Nov '18

Hello all, this probably hasn't been posted here so for everyone's info, there's a google spreadsheet created by IETF's Lee Howard, with information about transition mechanisms used by ISPs around the world. Obviously, anyone can edit and the more people add info, the more meaningful and useful it can become https://docs.google.com/spreadsheets/d/1ksOoWOaRdRyjZnjLSikHf4O5L1OUTNOO_7N… cheers, Yannis

1 0

New on RIPE Labs: IPv6 for Governments and Enterprises
by Mirjam Kuehne 23 Nov '18

23 Nov '18

Dear colleagues, Please find two new articles by Jordi Palet on RIPE Labs: IPv6 for Governments and Enterprises – a Case Study https://labs.ripe.net/Members/jordipaletm/ipv6-for-governments-and-enterpri… and Twelve Steps to Enable IPv6 in Government and Enterprise Networks https://labs.ripe.net/Members/jordipaletm/twelve-steps-to-enable-ipv6-in-go… Kind regards, Mirjam Kühne RIPE NCC

1 0

New on RIPE Labs: 10 Years of IPv6 Stakeout!
by Mirjam Kuehne 13 Nov '18

13 Nov '18

Dear colleagues, Please read on RIPE Labs how Torbjörn Eklöv is encouraging the municipalities in Sweden to deploy IPv6: https://labs.ripe.net/Members/teklov/10-years-of-ipv6-stakeout Kind regards, Mirjam Kühne RIPE NCC

1 0

IPv6 ipsec tunnel server on linux server
by Michael Hock 06 Nov '18

06 Nov '18

Hello, I'm trying to set up an ipsec server on a linux machine. The connection between clients and server should be IPv6 only but also needs to transport IPv4 packets. However, the linux kernel doesn't seem to support a feature which is required to transport IPv4 packets within an IPv6 ipsec connection, as shown here: https://wiki.strongswan.org/issues/939 Does maybe one of you know how to transport IPv4 packets in an IPv6 ipsec connection, or do we need to wait for the linux kernel to support this feature? Because this stops me from switching to IPv6 ipsec connections and I would like to reduce the usage of IPv4 as much as possible ... Sorry if this might be off-topic from the general IPv6 WG topics, but I thank you in advance for your time and answers! Best regards, Michael Hock

4 7

ipv6 francais: If you can read French...
by Jen Linkova 19 Oct '18

19 Oct '18

Very good document about IPv6 adoption in France (thanks Gordon for sharing!): https://www.arcep.fr/cartes-et-donnees/nos-publications-chiffrees/transitio… https://www.arcep.fr/fileadmin/reprise/observatoire/ipv6/Arcep_Barometre_20… -- SY, Jen Linkova aka Furry

2 1

New on RIPE Labs: iSEND: IPv6 SEcure Neighbor Discovery Implementation for Android Devices
by Mirjam Kuehne 16 Oct '18

16 Oct '18

Dear colleagues, Please read this new article on RIPE Labs by Ahmad Alsadeh: iSEND: IPv6 SEcure Neighbor Discovery Implementation for Android Devices With the help of the RIPE NCC Community Projects Fund, the project looks to achieve a solid implementation of iSEND for Android devices, which will help spread and accelerate the deployment of IPv6 in a secure manner. https://labs.ripe.net/Members/ahmad_alsadeh/isend Kind regards, Mirjam Kühne RIPE NCC

1 0

IPv6 WG Agenda (RIPE 77)
by Jetten Raymond 05 Oct '18

05 Oct '18

Hello, The draft agenda for the IPv6 WG session at RIPE 77 has been published, minor changes can still be made: https://ripe77.ripe.net/programme/meeting-plan/ipv6-wg/ Thanks, Ray, Jen and Benedikt

1 0