- ipv6-wg - mailman.ripe.net

IMPORTANT: RIPE75 is SPECIAL (call for presentations)
by Jen Linkova 24 Jul '17

24 Jul '17

Dear IPv6 Enthusiasts, We are building the agenda for the next meeting, so if you'd like to present at IPv6 WG sessions at RIPE75 or have some ideas/suggestions for the agenda - please contact ipv6-wg-chairs(a)ripe.net. IMPORTANT: There is smth unusual about RIPE75 you should be aware of, especially if you are planning to present. Dubai's Department of Tourism and Commerce Marketing (DCTM) have special requirements for events. The more detailed information could be found below in the text format (and the .docx is attached for your reference), but the short summary is: 1) a final list of all speakers at RIPE 75 must be provided to the DCTM one month before the start of the meeting; 2) all speakers (including remote presenters) need to provide a colour copy of their passport and a short bio (min 2000 chars). What does it means for us? Obviously we need to finalize the agenda much earlier than usual. Also those requirements make it very hard (almost impossible) to add new talks at the very last moment or deal with speakers change. Therefore if you are considering to present but still hesitating it's better to let us (chairs) know and submit a talk tentatively. Sorry about hassle and we hope to see as many amazing talks submitted as usual, despite all those irritating inconvenience! ;) Additional info: ---- Department of Commerce and Tourism Marketing (DTCM) Permit General information The application of a UAE law applies to all events held in Dubai including the RIPE 75 meeting. Following this local law, all speakers and attendees must provide additional personal information to the DTCM in advance of the meeting. While the impact will be minimal for attendees, the requirement to have speakers’ passports and other information weeks ahead of the meeting will require the RIPE Meeting agenda to be finalised much earlier than usual, and with less room for last-minute agenda changes. What are the requirements of the law? 1. All RIPE 75 attendees (including RIPE NCC staff) will need to provide the following information: Full name Country of residence Date of birth Nationality Telephone number (mobile or landline) Email address This information will be collected through our usual registration form and will be passed to the event agency that acts on behalf of the government. The event agency will use attendees’ information to produce barcodes for each attendee. The meeting badge will include the barcode and barcode number. 2. All speakers (including remote speakers) will need to email the following information to meeting(a)ripe.net one month before the start of the meeting. We will forward this information to the DTCM: Full name, title A colour copy of their passport A copy of their Emirates ID (if a UAE resident) Profile/bio for the speaker (at least 200 characters) Mobile number Email According to the law, a speaker will be rejected if any false information is submitted and a new application must be submitted. What does this mean for the WG Chairs and PC? The agendas for all WG sessions should be finalised one month before RIPE 75 begins, so that all presenters have time to submit their information/passports. The WG Chairs will need to make people aware of this deadline in their calls for presentations and when soliciting presentations for the meeting. We suggest that panels be avoided as much as possible, as it might be challenging logistically to ensure that speakers send in their information in time. Another option (“loophole”) would be to have the panel participants contribute as “audience members” from the floor. Who counts as a speaker? Essentially, this includes anyone who is presenting on stage - plenary and WG presenters, panel participants, WG Chairs and PC members and community members who are chairing or moderating sessions. Not included in this definition is attendees who are speaking at the microphones during Q&A sessions. Why does the government require this information? How will the data be handled? The stated reason is to facilitate greater efficiency for event organisers and government entities that are responsible for granting permits. The data is used to conduct analysis, market research and examine industry trends. The data is not shared with other event organisers or ticket resellers/registration companies. We have also been told that the real reason is for security (to avoid anti-government or anti-religious speakers). The information on attendees is also used to get an accurate sense of how many attendees were at the meeting. We do not know how long they will keep the information supplied or how it will be handled. Telephone numbers/email addresses will not be checked. What are the penalties for non-compliance? A fee is paid to the government for each individual case of incorrect data submitted. The attendee is liable for this, not the RIPE NCC. However, the DTCM has said if we show good faith, they will be understanding. Regarding the speakers, the fine is 5-15,000 AUD in the case of non-compliance. The RIPE NCC would be liable for this. Are any people exempted from these requirements? There are some options for a limited number of people to be exempted, but this is intended for high-level government attendees only. -- SY, Jen Linkova aka Furry on behalf of RIPE IPv6 WG Chairs.

11 12

New on RIPE Labs: Local Packet Filtering with IPv6
by Mirjam Kuehne 13 Jul '17

13 Jul '17

Dear colleagues, Please read this new article by Enno Rey on RIPE Labs where he discusses local packet filtering of IPv6, which might depend on the address configuration strategy chosen for your respective systems: https://labs.ripe.net/Members/enno_rey/local-packet-filtering-with-ipv6 Kind regards, Mirjam Kühne RIPE NCC

1 0

New on RIPE Labs: Simplifying IPv6 Addressing for Customers - Part 1
by Mirjam Kuehne 11 Jul '17

11 Jul '17

Dear colleagues, One of the main issues when an ISP is planning to deliver IPv6 services is to decide how to address the customers. In this first of two articles Jordi Palet Martinez looks into one of the issues related to IPv6 addressing for customers: the value of “persistence”. https://labs.ripe.net/Members/jordipaletm/simplifying-ipv6-addressing-of-cu… Kind regards, Mirjam Kühne RIPE NCC

2 2

IPv6 operations discussions
by Lee Howard 16 Jun '17

16 Jun '17

The IETF v6ops working group is chartered to improve the operation of IPv6. We have several active documents right now that would benefit from broader operator feedback. For instance, there is current active discussion on: Requirements for IPv6 Routers <https://tools.ietf.org/html/draft-ietf-v6ops-ipv6rtr-reqs> This document provides a list of requirements for operators’ routers. Is it clear and exhaustive? Basic Requirements for IPv6 Customer Edge Routers <https://tools.ietf.org/html/draft-ietf-v6ops-rfc7084-bis> What transition technologies should all CPE vendors put in their devices? The current version proposes all of: 464xlat, DS-Lite, lw4o6, MAP-E, MAP-T, 6in4, and 6rd, as well as IPv4 multicast over IPv6. There are related documents that split out some requirements for further discussion. Happy Eyeballs Version 2: Better Connectivity Using Concurrency <https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis> Is this a useful update to the existing Happy Eyeballs specification (rfc6555)? Should we update Happy Eyeballs? Considerations For Using Unique Local Addresses <https://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-considerations> Are ULAs useful, or are they a natural and risky predecessor to IPv6 NAT? It would help future IPv6 operations if current operators would read these documents and comment on them on the mailing list: https://www.ietf.org/mailman/listinfo/v6ops Note Well that comments become part of the IETF record, and thank you for them. Lee v6ops co-chair

1 0

New on RIPE Labs: Finding Open DNS Resolvers on IPv6
by Mirjam Kuehne 16 Jun '17

16 Jun '17

Dear colleagues, Please read this new article by Luuk Hendriks on how to find open DNS resolvers on IPv6: https://labs.ripe.net/Members/luuk_hendriks/finding-open-dns-resolvers-on-i… Kind regards, Mirjam Kühne RIPE NCC

1 0

New on RIPE Labs: What Stops IPv6 Traffic in a Dual-stack ISP?
by Mirjam Kuehne 14 Jun '17

14 Jun '17

Dear colleagues, Enric Pujol, network data analyst, is looking at barriers for dual-stack ISPs to carry IPv6 traffic: https://labs.ripe.net/Members/mirjam/what-stops-ipv6-traffic-in-a-dual-stac… Kind regards, Mirjam Kühne RIPE NCC

1 0

plea for increase participation in v6ops/IETF
by JORDI PALET MARTINEZ 13 Jun '17

13 Jun '17

Hello all, At the last LACNIC event, I mentioned on a couple of occasions the need for ISPs in the region, especially small and medium-sized ones, to participate in the decisions taken in the IETF IPv6 Operations Working Group (v6ops). I’m sending this here as well, as I believe the situation also apply to this region. When I asked among the attendees how many participate in v6ops, only one person raised his hand. What does it mean to participate in the mailing list? Follow some emails (sometimes only 1-2 a week, sometimes they can be several in a day), and therefore learn about what is being discussed and give your opinion and, given that decisions are made by Consensus, influence them. What consequences has NOT participating? That decisions against your interests/opinions could be taken, and obviously do not consider your perspective in the standards. Generally large operators are involved, which implies that your interests are not sufficiently represented, and in general are contrary to yours. Your "vote/opinion" is not worth more than yours, but the big one is present and the small/medium NO! I give you a very concrete example. The serious problem that small and medium ISPs have, is to continue offering IPv6 and IPv4 services to their customers, when they already do not have IPv4 addresses. Only the biggest ISPs have a great purchasing power and can influence the manufacturers to do for them what they need. One possibility to solve it, extending the life of IPv4, but not necessarily deploying IPv6, is using CGN, which is also very expensive, and breaks many things. The solution is simple. Deploying IPv6-only services in the last mile, which involves using transition mechanisms, such as 464XLAT that has been deployed on millions of smartphones worldwide, so that applications continue to operate transparently as they "believe" they have IPv4. What is the problem, then? That manufacturers of CPEs are based on an old specification (RFC7084) that does not contemplate these transition mechanisms, so when a small/medium ISP asks a manufacturer for a firmware upgrade or a new CPE, they do not include that solution and perhaps they offer it with an extra cost. In my view, this should change, and that is why I am working on a number of documents, including RFC7084-bis (https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc7084-bis/) To update this situation, but there is opposition from large ISPs and virtually no small/medium "talks" about it, and in fact these large ISPs deny the situation. In addition, the document also specifies the "automated" support of those cases in which the user installs other routers (which is very common as we all know, and will be more and more in IPv6, IoT, etc.), behind the router installed by the ISP, through homenet (HNCP). I am not asking for your support for my documents, but for understanding the problem and the solution that is being proposed and/or possible new ones, and for the opinion of not only those very few “big ones”, but also of many small and medium, who are most affected. If you want to subscribe to this list, search for "subscribing" at: https://www.ietf.org/mailman/listinfo/v6ops You can see the files of the discussion in: https://mailarchive.ietf.org/arch/search/?email_list=v6ops I remind you that participating in the IETF does not require a presence in the meetings, as consensus is agreed in the list. Regards, Jordi ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

1 0

New on RIPE Labs: 12 Steps to Enable IPv6 in an ISP Network
by Mirjam Kuehne 08 Jun '17

08 Jun '17

Dear colleagues, Please find this new article by Jordi Palet Martinez on RIPE Labs: "12 Steps to Enable IPv6 in an ISP Network" https://labs.ripe.net/Members/jordipaletm/12-steps-to-enable-ipv6-in-an-isp… Kind regards, Mirjam Kuhne RIPE NCC

1 0

New on RIPE Labs: 6th Anniversary of IPv6 Day and the next RIPE NCC Hackathon
by Mirjam Kuehne 06 Jun '17

06 Jun '17

Dear colleagues, We're celebrating the 6th anniversary of IPv6 Day with two IPv6 related articles on RIPE Labs: 6th Anniversary of the World IPv6 Day: https://labs.ripe.net/Members/nathalie_nathalie/6th-anniversary-of-the-worl… and Save the Date for the RIPE NCC IPv6 Hackathon in October: https://labs.ripe.net/Members/becha/save-the-date-ripe-ncc-hackathon-versio… Kind regards, Mirjam Kuhne RIPE NCC

1 0

New IPv6 Support for Governments Programme
by Mirjam Kuehne 17 May '17

17 May '17

Dear colleagues, Governments planning IPv6 deployments can now access assistance through our new IPv6 Support for Governments Programme. This is part of our ongoing efforts to work more closely with governments and encourage IPv6 adoption throughout our service region. We have explained our approach in more detail in a RIPE Labs article here: https://labs.ripe.net/Members/arne_kiessling/ipv6-support-for-governments-p… We have also documented this on our website here: https://www.ripe.net/manage-ips-and-asns/ipv6/ipv6-for-governments If you represent a government that is planning to make an IPv6 allocation request, please get in touch with us by emailing <IPv6forGov(a)ripe.net>. Kind regards, Mirjam Kuhne RIPE NCC

1 0

IPv6 prefix delegation BCOP document - draft v.2 for review.
by Jan Zorz - Go6 16 May '17

16 May '17

Dear RIPE IPv6 WG, As promised at BCOP TF meeting on Monday, the co-authors present at the RIPE74 meeting gathered on Tuesday afternoon and did some editorial work, addressing majority of the comments and suggestions we got from the community based on first version of the draft. Draft version 2 is now available for reading at https://sinog.si/docs/draft-IPv6pd-BCOP-v2.pdf We'll have a short "lightning talk" in Thursday IPv6 WG session, please go and read the document (those that have enough time and energy), so we get more feedback and input for further improvements (if needed). See you all in couple of hours! For co-authors team, Jan Žorž

7 15

RIPE73 meeting minutes
by Jen Linkova 08 May '17

08 May '17

Hello, I know I should have sent this email long time ago but better late than never... Anyway, the meeting minutes for RIPE73 IPv6 WG sessions could be found at https://www.ripe.net/participate/ripe/wg/ipv6/minutes/minutes-from-the-ipv6… Please review them (especially if you said anything at the mic), and let us know if there are any errors/omissions. Again, sorry for being late with sending this email. I'd also like to thank RIPE NCC for providing the meeting minutes! -- SY, Jen Linkova aka Furry on behalf of IPv6 WG chairs.

1 0

New on RIPE Labs: IPv6 RIPEness Through the Years
by Mirjam Kuehne 13 Apr '17

13 Apr '17

Dear colleagues, In 2010, we introduced IPv6 RIPEness to recognise Local Internet Registries in the RIPE NCC service region that had begun deploying IPv6. Seven years later, we looked at how the IPv6 RIPEness level of the RIPE NCC membership evolved over time. Please find some interesting results on RIPE Labs: https://labs.ripe.net/Members/wilhelm/ipv6-ripeness-through-the-years Kind regards, Mirjam Kuhne RIPE NCC

1 0

IPv6 prefix delegation BCOP document available for comments and suggestions
by Jan Zorz - Go6 13 Apr '17

13 Apr '17

Dear RIPE IPv6 WG, As promised at last RIPE meeting in Madrid, we produced a first draft of "Best Current Operational Practice for operators: IPv6 prefix assignment for end-users - static (stable) or dynamic (non-stable) and what size to choose." The aim of this document is to document the best current operational practice on what size of IPv6 prefix ISPs should assign/delegate to their customers and should they delegate it in a stable, static way or should it change over time. Please find the PDF attached and also accessible at: https://www.sinog.si/docs/draft-IPv6pd-BCOP-v1.pdf We are submitting this document to RIPE IPv6 WG (here) to check the technical validity of the document and also get consensus on it. We are also submitting it to RIPE BCOP TF to check if this is a real best operational practice and get consensus on it there. Please, read the document and send back comments to this mailing list. All feedback is more than welcome. On behalf of co-authors, Jan Žorž P.S: This document is not intended to document what practices may be in future and what they might look like, but to reflect the best methods of implementing IPv6 at the time of publication. Updates to this document will be published to reflect changes in best current practices where there are developments in standards and implementations.

13 30

ipv6-wg: SixXS is shutting down
by Pim van Pelt 28 Mar '17

28 Mar '17

Colleagues of RIPE's IPv6 working group, In 1999, Jeroen and I started SixXS, a project which aimed to provide IPv6 connectivity to users who wanted to learn about the network protocol and gain experience operating IPv6 networks. Our vision was to facilitate migration to IPv6 in content and access providers. We were able to provide IPv6 to 50’000+ individual users and companies in 140+ countries, using servers hosted at 40+ Internet providers in 30+ countries. We are incredibly proud of what we’ve accomplished together, and how many people have gotten to know all about IPv6 due to our combined efforts. We have completed a retrospective and rationale document, which details our experience developing and operating the SixXS tunnelbroker over the last 18 years. We have worked through our plans with the many dedicated ISPs that have been involved: https://www.sixxs.net/sunset/ We have reached out to users recently, giving them 6 weeks to make alternative plans. We have chosen a somewhat symbolic date of 2017-06-06 to turn down the SixXS service. Our website will remain as a tombstone. Please feel free to pass this along to any group or list you feel would benefit from it, and reach out to <info(a)sixxs.net> or to myself directly <pim(a)ipng.nl> if you have thoughts you’d like to share between now and then. Kindest Regards, Pim van Pelt and Jeroen Massar (SixXS founders) -- Pim van Pelt <pim(a)ipng.nl> PBVP1-RIPE - http://www.ipng.nl/

3 2

including a CLAT (464XLAT) SSID in RIPE meetings
by JORDI PALET MARTINEZ 24 Mar '17

24 Mar '17

Hi all, I was suggesting the NCC OPS team to include in the meeting network a VM machine that provides a “CLAT” SSID in the meeting network. They suggested that, same as it was done for the NAT64 SSID, the topic is discussed in the IPv6 WG, as there is not a “formal” procedure to agree on that. So, I checked with the IPv6 WG co-chairs and they asked me to foster this topic in the mailing list … so here we are. While 464XLAT has been extensively tested and deployed in the cellular world, I think most of the wireline and wireless (not cellular) ISPs, haven even heard about it or evaluated the potential for those environments, the same that happens probably with MAP-T/E. Having just a NAT64 gives the impression to the people that today you can deploy IPv6-only access to customers and we know is not the case, because the app. Even if 80% (which will take YEARS to happen) of the app developers “correct” their apps, you will still get many things broken in homes and offices. So is undesirable (in my opinion) to work (only) in that direction. And even more, those apps, hardware, etc., that will never be updated, will never work with a NAT64-only scenario. With 464XLAT (or MAP), you avoid deploying CGN, which is a high cost, and you provide the *same* functionality that today “regular” customers (residential, SMEs, even many big companies that don’t have to export IPv4 services outside their LANs). If we demonstrate this “live” in the RIPE meeting network, I think we can change some of the participant’s minds, and I believe the cost of that is really small, may be a couple of hours of one of your OPS team colleagues, as I’ve already done the work and I’m happy to help them on testing in their lab, document what I’ve done (already working on that), and anything else they may need. Also, if the NAT64 is already there, it becomes much easier, as only the VM with the CLAT is needed (unless you want to “separate” the NAT64 for each SSID). By the way, the plan is to have this also in the next meetings of other RIRs (already planned). So, opinions? Regards, Jordi ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

2 2

QUESTION FOR IPV6
by h.essa 22 Mar '17

22 Mar '17

Hi please Iwant spesific answer ; if I become LIR i WILL have package of IPV6 or onley Ipv4/22 THANKS

4 3

New on RIPE Labs: IPv6 Train The Trainer
by Nathalie Trenaman 20 Mar '17

20 Mar '17

Dear colleagues, I just published a RIPE Labs article about our IPv6 Train The Trainer project we are working on in the MENOG and ENOG region. We are very proud of our team of experienced, competent local trainers that are building IPv6 communities and spreading knowledge in their countries. You can read all about it here: https://labs.ripe.net/Members/nathalie_nathalie/ipv6-train-the-trainer <https://labs.ripe.net/Members/nathalie_nathalie/ipv6-train-the-trainer> Nathalie Künneke-Trenaman IPv6 Program Manager RIPE NCC

2 1

RIPE74 - call for presentations
by Jen Linkova 13 Mar '17

13 Mar '17

Hi there ;) If you'd like to present at IPv6 WG sessions at RIPE74 or have some ideas/suggestions for the agenda - please contact ipv6-wg-chairs(a)ripe.net. Thanks and see you in Budapest! --- On behalf of IPv6 WG Chairs, Jen Linkova aka Furry

1 0

Fwd: New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt)
by Fernando Gont 28 Feb '17

28 Feb '17

Folks, FYI: <https://tools.ietf.org/html/draft-gont-v6ops-host-configuration-00> Abstract: IPv6 has two different mechanisms for dynamic/automatic host configuration: SLAAC and DHCPv6. These two mechanisms allow for the configuration of IPv6 addresses and a number of network parameters. While there is overlap in the parameters that can be configured via these two protocols, different implementations support only subsets of such parameters with either mechanism, or have no support for DHCPv6 at all. This document analyzes a problem that arises from this situation, and mandates that all host implementations support RFC 6105 (DNS options for SLAAC) and the stateless DHCPv6 functionality in RFC 3315. This document is targetted at the IETF v6ops wg. Please send your comments there (if possible), but we'll be happy to discuss this doc on this list, too. Thanks! Fernando (and co-authors) -------- Forwarded Message -------- Subject: New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) Date: Tue, 28 Feb 2017 05:13:25 -0300 From: Fernando Gont <fgont(a)si6networks.com> To: IPv6 Operations <v6ops(a)ietf.org> Folks, Based on a recent discussion regarding the problem of conveying DNS information in IPv6 networks, we have submitted this short I-D, in the hopes of getting the aforementioned problem solved. Your feedback will be appreciated. Thanks! Fernando (and co-autors) -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-v6ops-host-configuration-00.txt Date: Mon, 27 Feb 2017 23:51:03 -0800 From: internet-drafts(a)ietf.org To: Fernando Gont <fgont(a)si6networks.com>, Gert Doering <gert(a)space.net>, Madelen Garcia Corbo <madelen.garcia16(a)gmail.com>, Madelen Corbo <madelen.garcia16(a)gmail.com>, Guillermo Gont <ggont(a)si6networks.com> A new version of I-D, draft-gont-v6ops-host-configuration-00.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-v6ops-host-configuration Revision: 00 Title: On the Dynamic/Automatic Configuration of IPv6 Hosts Document date: 2017-02-27 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-gont-v6ops-host-configuration-00… Status: https://datatracker.ietf.org/doc/draft-gont-v6ops-host-configuration/ Htmlized: https://tools.ietf.org/html/draft-gont-v6ops-host-configuration-00 Abstract: IPv6 has two different mechanisms for dynamic/automatic host configuration: SLAAC and DHCPv6. These two mechanisms allow for the configuration of IPv6 addresses and a number of network parameters. While there is overlap in the parameters that can be configured via these two protocols, different implementations support only subsets of such parameters with either mechanism, or have no support for DHCPv6 at all. This document analyzes a problem that arises from this situation, and mandates that all host implementations support RFC 6105 (DNS options for SLAAC) and the stateless DHCPv6 functionality in RFC 3315. 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

New on RIPE Labs: Commercial Incentives of IPv6 Deployment
by Mirjam Kuehne 22 Feb '17

22 Feb '17

Dear colleagues, Please find a new article on RIPE Labs. It is based on the IPv6 Best Practices document published for the Internet Governance Forum 2016 by Izumi Okutani, Sumon A. Sabir and Wim Degezelle. https://labs.ripe.net/Members/mirjam/commercial-incentives-of-ipv6-deployme… Kind regards, Mirjam Kuhne RIPE NCC

1 0

New on RIPE Labs: Bugfixing IPv6 Deployment Statistics
by Mirjam Kuehne 20 Feb '17

20 Feb '17

Dear colleagues, Unfortunately we found a bug in the dataset that shows the percentage of ASes announcing an IPv6 prefix. Please find the details on RIPE Labs: https://labs.ripe.net/Members/emileaben/bugfixing-ipv6-deployment-statistics Kind regards, Mirjam Kuhne RIPE NCC

1 0

New on RIPE Labs: IPv6 RIPEness in 2017
by Mirjam Kuehne 13 Feb '17

13 Feb '17

Dear colleagues, This new post on RIPE Labs provides an update on our IPv6 RIPEness project, including an analysis of IPv6 RIPEness for new Local Internet Registries: https://labs.ripe.net/Members/wilhelm/ipv6-ripeness-update Kind regards, Mirjam Kuhne RIPE NCC

1 0

Updated NOG wiki
by Michael Oghia 08 Feb '17

08 Feb '17

Dear colleagues, I went through and updated the NOG Wikipedia page this morning. Feel free to add resources/links, or additional NOGs that are not listed: https://en.wikipedia.org/wiki/Internet_Network_Operators%27_Groups Best, -Michael __________________ Michael J. Oghia iGmena <http://igmena.org/> communications manager Independent #netgov consultant & editor Belgrade, Serbia Skype: mikeoghia Twitter <https://www.twitter.com/MikeOghia> *|* LinkedIn <https://www.linkedin.com/in/mikeoghia>

1 0

high v6 user-base, less atlas probes.
by Vaibhav Bajpai 28 Jan '17

28 Jan '17

Hello, -- sorry for cross-posting Here is a list of top 20 countries that have a large v6 user-base [*] but are underrepresented by RIPE Atlas due to less number of deployed dual-stacked probes. Consider hosting a dual-stacked probe in these regions to help remove the region-based bias that v6 studies using RIPE Atlas may otherwise have: Full paper available here: http://goo.gl/hWGveA (§4) +----+------------+-----------| | CC | v6 Users | v6 Probes | |-----+----+------------+-----------| | 01 | BE | 56.48 % | 2.82 % | | 02 | LU | 35.23 % | 0.61 % | | 03 | GR | 33.66 % | 1.39 % | | 04 | CH | 33.48 % | 3.82 % | | 05 | PT | 29.01 % | 0.74 % | | 06 | IN | 22.25 % | 0.09 % | | 07 | US | 33.00 % | 13.21 % | | 08 | DE | 40.07 % | 21.25 % | | 09 | EC | 18.76 % | 0.04 % | | 10 | JP | 19.69 % | 1.35 % | | 11 | GB | 24.63 % | 7.00 % | | 12 | EE | 16.55 % | 0.26 % | | 13 | CA | 17.83 % | 1.91 % | | 14 | FI | 16.68 % | 1.39 % | | 15 | MY | 14.90 % | 0.13 % | | 16 | IE | 13.22 % | 0.87 % | | 17 | NO | 14.02 % | 1.83 % | | 18 | BR | 12.56 % | 0.83 % | | 19 | AU | 12.76 % | 1.09 % | |-----+----+------------+-----------| [*] The estimation of number of IPv6 users is taken from APNIC dataset: http://labs.apnic.net/dists/v6dcc.html -- Vaibhav -------------------------- Vaibhav Bajpai www.vaibhavbajpai.com Postdoctoral Researcher TU Munich, Germany --------------------------

1 0