- ipv6-wg - mailman.ripe.net

v4 versus v6 -- who connects faster?
by Bajpai, Vaibhav 23 May '16

23 May '16

Dear v6 WG, Here [a] is a toy v6 service I came up with during the RIPE Atlas hackathon over this weekend. Thought I share this along: [a] http://goo.gl/hbzbwD You enter a dual-stacked website (ALEXA top 10K) and it shows you the difference in TCP connect times over v4 and v6 as seen by all dual-stacked RIPE Atlas probes (~1.3K probes). You can also filter the visualisation from a specific origin-AS. This additional filter can be useful to view performance towards a website from a specific origin-AS (say 3320). Disclaimer: This is an outcome of a 1.5d long hackathon project. As such, the codebase is possibly inundated with bugs. Please don’t see it as a production service :-) Best, Vaibhav =================================== Vaibhav Bajpai www.vaibhavbajpai.com<http://www.vaibhavbajpai.com> Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany ===================================

2 1

Re: [ipv6-wg] v4 versus v6 -- who connects faster?
by Eric Vyncke (evyncke) 23 May '16

23 May '16

Hello Vaibhav, The map with blue/red is really a nice one :-) May I dare to propose some improvements? * on the blue/red map, be sure to have blue meaning all the time that IPv6 is faster (the legend is unclear and by using those tools, I know that this is not trivial to do) * State the date of the 'scan' * Some web sites are in the top 10K of Alexa but are not in: www.iet.org, www.lesoir.be, .... (Even www.ripe.net is not in the data :-) but RIPE is only 25.000th so out of your data set) Again, nice visualisation! -éric From: ipv6-wg <ipv6-wg-bounces(a)ripe.net<mailto:ipv6-wg-bounces@ripe.net>> on behalf of "Bajpai, Vaibhav" <v.bajpai(a)jacobs-university.de<mailto:v.bajpai@jacobs-university.de>> Date: Monday 23 May 2016 at 08:08 To: "ipv6-wg(a)ripe.net<mailto:ipv6-wg@ripe.net> IPv6" <ipv6-wg(a)ripe.net<mailto:ipv6-wg@ripe.net>> Subject: [ipv6-wg] v4 versus v6 -- who connects faster? Dear v6 WG, Here [a] is a toy v6 service I came up with during the RIPE Atlas hackathon over this weekend. Thought I share this along: [a] http://goo.gl/hbzbwD You enter a dual-stacked website (ALEXA top 10K) and it shows you the difference in TCP connect times over v4 and v6 as seen by all dual-stacked RIPE Atlas probes (~1.3K probes). You can also filter the visualisation from a specific origin-AS. This additional filter can be useful to view performance towards a website from a specific origin-AS (say 3320). Disclaimer: This is an outcome of a 1.5d long hackathon project. As such, the codebase is possibly inundated with bugs. Please don’t see it as a production service :-) Best, Vaibhav =================================== Vaibhav Bajpai www.vaibhavbajpai.com<http://www.vaibhavbajpai.com> Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany ===================================

2 1

IPv6 residential deployment survey (looking into technical aspects)
by JORDI PALET MARTINEZ 20 May '16

20 May '16

Hi all, I got so much input for a small “email survey”, that I’ve decided to make it more complete and on-line. The results will be published and updated every month or so, I will provide ASAP the link to those stats. No personal data will be published. http://survey.consulintel.es/index.php/175122 (If you know your network, it takes less than 2 minutes to complete it) It can be responded even if is not yet a commercial service, and customers can also respond, not just the ISP. However, to avoid duplicate data, make sure to include the country and ISP name. For those that already replied to me by email, it will be much better if you can fill in the on-line survey. Otherwise, after a week or so, I will input “manually” the data that you provided, but then there will be many “empty” questions. Please, feel free to circulate this message as much as you can ! Thanks a lot! 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: IPv6 Fragmentation (by Geoff Huston)
by Mirjam Kuehne 19 May '16

19 May '16

Dear colleagues, Please find this new article on "Fragmenting IPv6" by Geoff Huston on RIPE Labs: https://labs.ripe.net/Members/gih/fragmenting-ipv6?pk_campaign=labs&pk_kwd=… Kind regards, Mirjam Kuehne RIPE NCC

1 0

IPv6 residential service: What prefix, static, dynamic, extra cost ?
by JORDI PALET MARTINEZ 19 May '16

19 May '16

Hi all, I’m trying to make a table to compare the way actual IPv6 services to residential customers are being provissioned mainly in EU, but I will do to the same also in other regions. I’m happy to make a single “table” with all the information that I can collect and publish it so others can make use of it, and keep it updated, may be in some URL, etc. So here are the questions for actual IPv6 services providers to residential customers: 1) What prefix size is provided? 2) Is that prefix static or dynamic? 3) In case is dynamic, there is a chance for static? 4) Any extra cost for having it static, or having a bigger prefix (i.e., /48 instead of /56)? 5) If the customer has already a static IPv4 with a monthly charge, is still IPv6 static prefix being charged on top of that? Please state the ISP name, country and if you have a URL or document that state this service, other options, etc. If you’re not yet providing the service, but it will happen soon and the “model” for this has been already defined, please let me know as well! Hopefully I can get a lot of anwers! Private or in the list, I’m fine either way. Thanks! Regards, Jordi PD: In my opinion it should be /48 by default, static and opt-in to dynamic, no extra charge on top of the Internet service price, but I know many ISPs will not agree :-( Here just trying to collect the info in a single place. ********************************************** 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.

15 21

Re: [ipv6-wg] IPv6 cloud!
by Benedikt Stockebrand 12 May '16

12 May '16

Hi Ole and list, "Ole Troan (otroan)" <otroan(a)cisco.com> writes: >> Considering the increasing reports of people having problems with >> DS-Lite > > Any more details on that? > New problems not mentioned in RFC6269? sorry I haven't got the time right now to review RFC6269 for what's exactly mentioned there and what isn't, but: When I do IPv6 trainings these days it's about one in eight who is struggling with their land line access, which is based on DS-Lite and which reasonably well matches the estimated percentage of DS-Lite on land lines. The problems are however of a somewhat different nature than what RFC6269 addresses; they are roughly these: - Various services don't work. Like STUN, and due to that, SIP. And apparently various VPN solutions, too, but I never got access to any details with this. The real culprit here seems to be restricted cone NAT in the AFTR, plus apparently IPsec not working through DS-Lite. - There have been multiple reports that during peak hours there are significant connection drops. The impact varies from user to user as well as from ISP to ISP, apparently. Or as one user put it: "I solved the problem. I just don't even try to access IPv4-only web pages on saturday afternoons any longer." I don't have access to the AFTRs involved, so I can't reliably tell what's happening there, but from the descriptions I got it looks like some of them are actually running out of memory/CAM during peak hours and start to drop the connections. This is economically plausible, too, since the ISPs won't spend significant money on AFTR hardware until problems have already shown up. - First level support is frequently completely helpless when confronted with DS-Lite, or even IPv6 in general. The most annoying aspect here is that frequently it comes across that "it's a problem with IPv6" and "if you keep complaining they'll switch it off again for you" (i.e. they go back to IPv4-only connectivity without restricted cone NAT). All the information I have here is largely based on anecdotal reports, but enough of them for me to consider these problems anything but isolated cases. Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/

3 4

Re: [ipv6-wg] ipv6-wg Digest, Vol 55, Issue 4 -NAT64 Benedikt Stockebrand
by Thorsten Trottier 05 May '16

05 May '16

Hello Benedikt, I’m not a friend of NAT as well, but demonize NAT for any actions is a kind of overdo, isn’t it. We are living with NAT a long time now for better or for worse. A customer of mine (enterprise customer with hundreds of sites and thousands of employees) has setup his IPv6 project more than 4 years ago and plans to be finished 2020. Their project team produced hundreds of pages in planning strategy, timeline and migration. In one of their sub projects they saw NAT as a interim solution for their Webservice as best method. We implemented a redundant NAT64 solution based on Cisco Adress Family Translation. Now IPv6-only or Dual-stacked Users can hit the customers web service which is still IPv4 only. Of course not a low-cost solution, but for „political" and/or technical reasons a solid way. Best regards Thorsten > > > -----Ursprüngliche Nachricht----- > Von: ipv6-wg [mailto:ipv6-wg-bounces@ripe.net] Im Auftrag von ipv6-wg-request(a)ripe.net > Gesendet: Dienstag, 26. April 2016 12:00 > An: ipv6-wg(a)ripe.net > Betreff: ipv6-wg Digest, Vol 55, Issue 4 > > Send ipv6-wg mailing list submissions to > ipv6-wg(a)ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.ripe.net/mailman/listinfo/ipv6-wg > or, via email, send a message with subject or body 'help' to > ipv6-wg-request(a)ripe.net > > You can reach the person managing the list at > ipv6-wg-owner(a)ripe.net > > When replying, please edit your Subject line so it is more specific than "Re: Contents of ipv6-wg digest..." > > > Today's Topics: > > 1. Re: ipv6-wg Digest, Vol 55, Issue 2 (Benedikt Stockebrand) > 2. Re: ipv6-wg Digest, Vol 55, Issue 2 (Silvia Hagen) > 3. Re: ipv6-wg Digest, Vol 55, Issue 2 (Sander Steffann) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 25 Apr 2016 18:13:35 +0000 > From: Benedikt Stockebrand <bs(a)stepladder-it.com> > To: christian bretterhofer <christian.bretterhofer(a)gmail.com> > Cc: ipv6-wg(a)ripe.net > Subject: Re: [ipv6-wg] ipv6-wg Digest, Vol 55, Issue 2 > Message-ID: <87eg9th7zk.fsf(a)moa.stepladder-it.com> > Content-Type: text/plain > > Hi Christian and list, > > christian bretterhofer <christian.bretterhofer(a)gmail.com> writes: > >> I think the basic work for ISPs in concern to IPv6 is covered. > > well, depends on the ISP in question. To me it looks a lot like many are still struggling to get the necessary knowledge and experience to their tech and support crowd---not necessarily with the people actively involved in the RIPE community, but at least with the big ones. > > A customer recently asked one of the large players here in Germany if they were interested in a contract that would have allowed my customer to outsource some IPv6-related tasks---or rather, to outsource some tasks that were also expected to be supported via IPv6. They were turned down with the explanation "we don't have the necessary manpower to operate this". > >> But i miss the topics to be addressed if you want to migrate from a >> IPv4 Microsoft Active domain using company to an system where most >> server in an enterprise could by just IPv6 only and use technologies >> like NAT46 ( SIIT-DC ) or similar to still make IPv4 only windows >> clients happy. > > Now I've taken a bit of a look at these things, but then I'm not exactly a Microsoft guy. From all I've seen, going for NAT64 and such is generally a bad idea. Instead, ensure that IPv6 is provided wherever it is needed and then make your servers dual stacked. > > Yes, that frequently involves upgrades on various servers nobody really wants to touch, but the very reasons why nobody wants to touch them are the reasons why you actually clean that stuff up. > >> Switching an enterprise with location around the global from a "we >> donot route any IPv6 traffic across our WAN Links" "most servers have >> IPv6 disabled" to >> We start IPv6 routing partially and enable partial IPv6 support on >> servers in a Microsoft ADS environment seems not covered in most IPv6 >> covering websites and presentations. > > That may be because your approach is unnecessarily painful. You want to get IPv6 up and running in the network infrastructure first, then make your servers dual-stacked and then deal with the clients. > > At least that's the "strategic" outline of an approach. Beyond that it's really a lot of detail work to do on an individual basis. > >> Maintaining dual stack for the datacenters is just painfull and there >> should be a "single" device in the form of NAT46/SIIT/SIIT-DC in front >> of each server area. I am not sure that Active directory is ready for >> that. > > Nonononono, don't do that. Whenever something goes wrong with that "single device", you'll have a serious disruption of service, not everything works through it, and you'll never ever get a chance to get rid of it in the long run because there'll always be that one last server that depends on it, or might depend on it but nobody knows for sure. > > Yes, that means that you need to have all your servers dual stacked, and yes, that's some serious extra workload in a data center context, but anything else is quite likely way worse. > > > Cheers, > > Benedikt > > -- > Benedikt Stockebrand, Stepladder IT Training+Consulting > Dipl.-Inform. http://www.stepladder-it.com/ > > Business Grade IPv6 --- Consulting, Training, Projects > > BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/ > > > > ------------------------------ > > Message: 2 > Date: Mon, 25 Apr 2016 18:35:28 +0000 > From: Silvia Hagen <silvia.hagen(a)sunny.ch> > To: Benedikt Stockebrand <bs(a)stepladder-it.com>, christian > bretterhofer <christian.bretterhofer(a)gmail.com> > Cc: "ipv6-wg(a)ripe.net" <ipv6-wg(a)ripe.net> > Subject: Re: [ipv6-wg] ipv6-wg Digest, Vol 55, Issue 2 > Message-ID: <F1D4404E5E6C614EB9D3083F4D15A7E70129FFFA@hex02> > Content-Type: text/plain; charset="iso-8859-1" > > That would be a great panel discussion with some diverse speakers on the panel :-) > > Silvia > > -----Urspr?ngliche Nachricht----- > Von: ipv6-wg [mailto:ipv6-wg-bounces@ripe.net] Im Auftrag von Benedikt Stockebrand > Gesendet: Montag, 25. April 2016 20:14 > An: christian bretterhofer > Cc: ipv6-wg(a)ripe.net > Betreff: Re: [ipv6-wg] ipv6-wg Digest, Vol 55, Issue 2 > > Hi Christian and list, > > christian bretterhofer <christian.bretterhofer(a)gmail.com> writes: > >> I think the basic work for ISPs in concern to IPv6 is covered. > > well, depends on the ISP in question. To me it looks a lot like many are still struggling to get the necessary knowledge and experience to their tech and support crowd---not necessarily with the people actively involved in the RIPE community, but at least with the big ones. > > A customer recently asked one of the large players here in Germany if they were interested in a contract that would have allowed my customer to outsource some IPv6-related tasks---or rather, to outsource some tasks that were also expected to be supported via IPv6. They were turned down with the explanation "we don't have the necessary manpower to operate this". > >> But i miss the topics to be addressed if you want to migrate from a >> IPv4 Microsoft Active domain using company to an system where most >> server in an enterprise could by just IPv6 only and use technologies >> like NAT46 ( SIIT-DC ) or similar to still make IPv4 only windows >> clients happy. > > Now I've taken a bit of a look at these things, but then I'm not exactly a Microsoft guy. From all I've seen, going for NAT64 and such is generally a bad idea. Instead, ensure that IPv6 is provided wherever it is needed and then make your servers dual stacked. > > Yes, that frequently involves upgrades on various servers nobody really wants to touch, but the very reasons why nobody wants to touch them are the reasons why you actually clean that stuff up. > >> Switching an enterprise with location around the global from a "we >> donot route any IPv6 traffic across our WAN Links" "most servers have >> IPv6 disabled" to >> We start IPv6 routing partially and enable partial IPv6 support on >> servers in a Microsoft ADS environment seems not covered in most IPv6 >> covering websites and presentations. > > That may be because your approach is unnecessarily painful. You want to get IPv6 up and running in the network infrastructure first, then make your servers dual-stacked and then deal with the clients. > > At least that's the "strategic" outline of an approach. Beyond that it's really a lot of detail work to do on an individual basis. > >> Maintaining dual stack for the datacenters is just painfull and there >> should be a "single" device in the form of NAT46/SIIT/SIIT-DC in front >> of each server area. I am not sure that Active directory is ready for >> that. > > Nonononono, don't do that. Whenever something goes wrong with that "single device", you'll have a serious disruption of service, not everything works through it, and you'll never ever get a chance to get rid of it in the long run because there'll always be that one last server that depends on it, or might depend on it but nobody knows for sure. > > Yes, that means that you need to have all your servers dual stacked, and yes, that's some serious extra workload in a data center context, but anything else is quite likely way worse. > > > Cheers, > > Benedikt > > -- > Benedikt Stockebrand, Stepladder IT Training+Consulting > Dipl.-Inform. http://www.stepladder-it.com/ > > Business Grade IPv6 --- Consulting, Training, Projects > > BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/ > > > > > ------------------------------ > > Message: 3 > Date: Mon, 25 Apr 2016 19:45:27 +0100 > From: Sander Steffann <sander(a)steffann.nl> > To: Silvia Hagen <silvia.hagen(a)sunny.ch> > Cc: christian bretterhofer <christian.bretterhofer(a)gmail.com>, > "ipv6-wg(a)ripe.net" <ipv6-wg(a)ripe.net> > Subject: Re: [ipv6-wg] ipv6-wg Digest, Vol 55, Issue 2 > Message-ID: <0831019F-B2A2-40DB-99E4-9CAA526D1581(a)steffann.nl> > Content-Type: text/plain; charset="iso-8859-1" > > Hi, > >> Op 25 apr. 2016, om 19:35 heeft Silvia Hagen <silvia.hagen(a)sunny.ch> het volgende geschreven: >> >> That would be a great panel discussion with some diverse speakers on >> the panel :-) > > I have been doing some enterprise stuff as well recently. If there is going to be such a panel I would love to participate! :) > > Cheers, > Sander > >

2 1

what is v6-only?
by Bajpai, Vaibhav 05 May '16

05 May '16

Hello, What does v6-only mean? a) A client only has v6 address and can only route to v6 destinations b) A client only has v6 address but can route to dual-stack destinations using a network translator (such as NAT64) IIRC, IETF SSIDs are named: 'v6 only + nat64’. Personally when someone says v6-only I presume a), but lately I have seen people say v6-only although they mean b). PS: Sorry for a silly question Best, Vaibhav =================================== Vaibhav Bajpai www.vaibhavbajpai.com Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany ===================================

5 4

IPv6 WG Agenda
by Jen Linkova 03 May '16

03 May '16

Hi IPv6-Enthusiasts ;) I'm sure most of you have noticed that already, but the agenda for IPv6 WG sessions @ RIPE72 has been published: https://ripe72.ripe.net/programme/meeting-plan/ipv6-wg/ See you in Copenhagen soon! -- SY, Jen Linkova aka Furry on behalf of IPv6 WG Chairs

1 0

RIPE72 IPv6 WG: call for presentations
by Jen Linkova 20 Apr '16

20 Apr '16

Dear IPv6 Enthusiasts ;) I know that 23 of May 2016 when RIPE72 will start looks so away but we (IPv6 WG Chairs) like to plan ahead! If you would like to present at IPv6 WG session or just have any suggestions on the agenda (what we should or should not be talking about) - please email ipv6-wg-chairs(a)ripe.net >From presenters we need the following information: - a tentative title of your talk; - short summary - how much time you need (I'd recommend allowing 5 mins for questions). For the last few meetings we filled all the agenda slots quite earlier and unfortunately had to reject a number of interesting talks because they were submitted too late. So don't be shy! If you *might* be able to present but not sure yet - also let us know. -- SY, Jen Linkova aka Furry on behalf of IPv6 WG Chairs.

3 2

New on RIPE Labs: 10,000 LIRs with IPv6 Resources
by Mirjam Kuehne 29 Feb '16

29 Feb '16

Dear colleagues, This week, we saw the 10,000th Local Internet Registry (LIR) received IPv6 addresses. The first block of IPv6 addresses was allocated from IANA to the RIPE NCC in 1999, so we have been distributing IPv6 addresses for 17 years. In this new article on RIPE Labs we track the policy developments that have made it progressively easier for LIRs to get the IPv6 they need: https://labs.ripe.net/Members/nathalie_nathalie/10-000-lirs-with-ipv6-resou… Kind regards, Mirjam Kuehne RIPE NCC

2 1

[training] RIPE NCC Training Courses April-June 2016
by Training Services 29 Feb '16

29 Feb '16

Dear colleagues, Our training team travels the RIPE NCC service region to deliver training courses to our members without any additional cost. Over the next few months, we'll be in Budapest, Tirana, Manchester, Lisbon, Bologna, Munich, Tallinn, Moscow, Vienna, Valletta, Reykjavik. Visit the following page to register and to check which training courses we are giving in your area: https://lirportal.ripe.net/training/courses The RIPE NCC delivers the following training courses: - LIR Training Course - RIPE Database Training Course - Basic IPv6 Training Course - DNSSEC Training Course - 2 days Advanced IPv6 Training Course - 2 days BGP Operations and Security Training Course For more information visit: https://www.ripe.net/support/training/courses With kind regards, Rumy Spratley-Kanis Training Services Manager

1 0

Internet question for opensubscriber.com
by Jack 15 Feb '16

15 Feb '16

Hello, I just need a bit of help, I would like to send the person who is authorised to make changes to opensubscriber.com a link to be added to this page: http://www.opensubscriber.com/message/ipv6-wg@ripe.net/17177495.html or to a resource page. I think it will be a great addition to the resources on the internet. The resource is an in-depth infographic filled with data of how the internet has evolved and had an impact on the transport industry. It also has a great internet timeline to show some of its milestones. This is the link to the graphic: https://www.locator.co.uk/vans. Let me know what you think? Also if this is not the correct email address to send this to, can you please let me know or forward this message on to the correct person? Thank you for your time, Jack ALL GREEN PR LIMITED, Kemp House, 152 City Road, London EC1V 2NX Remove me from Jack's list

1 0

IETF I-D: "Operational Implications of IPv6 Packets with Extension Headers"
by Fernando Gont 10 Feb '16

10 Feb '16

Folks, We have revised our IETF I-D "Operational Implications of IPv6 Packets with Extension Headers". The I-D is available at: <https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-01> Your feedback will be appreciated. If possible, please send your comments to: <draft-gont-v6ops-ipv6-ehs-packet-drops(a)tools.ietf.org> and CC <v6ops(a)ietf.org>. P.S.: You can find a number of pointers to articles and other related work on this topic here: <http://blog.si6networks.com/2015/12/the-controversial-ipv6-extension-header…> Thanks! Best regards, -- 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

2 2

New on RIPE Labs: Evaluating IPv4 and IPv6 Packet Fragmentation (by Geoff Huston)
by Mirjam Kuehne 29 Jan '16

29 Jan '16

Dear colleagues, Please find a new article on RIPE Labs contributed by Geoff Huston: Evaluating IPv4 and IPv6 Packet Fragmentation: One of the more difficult design exercises in packet-switched network architectures is that of the design of packet fragmentation. In this article, I’d like to examine IP packet fragmentation in detail and look at the design choices made by IP version 4, and then compare that with the design choices made by IP version 6. https://labs.ripe.net/Members/gih/evaluating-ipv4-and-ipv6-packet-fragmenta… Kind regards, Mirjam Kuehne RIPE NCC

1 0

New on RIPE Labs: Behind the Curtain - Making IPv6 Work
by Mirjam Kuehne 26 Jan '16

26 Jan '16

Dear colleagues, Please find a new article on RIPE Labs contributed by George Michaelson from APNIC: https://labs.ripe.net/Members/ggm/behind-the-curtain-making-ipv6-work Kind regards, Mirjam Kuehne RIPE NCC

1 0

Users turning off IPv6 because of YouTube
by Ondřej Caletka 14 Jan '16

14 Jan '16

Hello list, I've came across a new reason people are turning off IPv6 on their computers. Looks like GeoIP restrictions of YouTube are somehow broken making some videos playable over IPv4 but 'not accessible from your country' over IPv6. For example this music video: https://www.youtube.com/watch?v=44XYEeD1A1U is perfectly playable from addresses: 147.32.0.0/16 and 195.113.0.0/16 but not playable from 2001:718::/32 The network is deployed as native dualstack and both address families are correctly registered in the RIPE database to Prague. I guess there's probably nothing we can do from the network operator's point of view. Anyone experiencing the same? Cheers, Ondřej Caletka CESNET

5 5

[training] RIPE NCC Webinars - new dates
by Training Services 13 Jan '16

13 Jan '16

Dear colleagues, We are pleased to announce the launch of new dates for our Webinars. The RIPE NCC Webinars are live and take only one hour. You can interact with our trainers without leaving your desk. We focus on the topics and issues most important for LIRs. Register now at https://www.ripe.net/lir-services/training/e-learning/webinars Participation is limited to 20 people, so don't hesitate if you want to take part! If you have questions, please email <training(a)ripe.net>. We look forward to seeing you online. Kind regards, RIPE NCC Training Services

1 0

IGF 2015 output document: "Creating an Enabling Environment for IPv6 Adoption"
by Marco Hogewoning 09 Dec '15

09 Dec '15

Dear colleagues, In earlier emails we asked you to review the draft outcome document for the Internet Governance Forum (IGF) Best Practice Forum on IPv6. This is to let you know the 2015 IGF inter-sessional work has now concluded and the final output document has been published on the IGF website. It is available for download at: http://goo.gl/BXBzTn Acknowledging the need for a increased rate of IPv6 adoption, the documents highlights numerous examples and best practices that can help businesses and governments with their IPv6 deployment projects. A large section of the document is dedicated to role and function of IPv6 task forces, which can be instrumental to a successful IPv6 deployment in a particular country or region. In addition it provides an overview of various capacity building programs that are available, which includes the RIPE NCC Training Courses and IPv6 Roadshows. We hope this document provides useful guidance for our community members and stakeholders that face the important step of enabling IPv6 in their networks and services. We would like to thank everybody who contributed to this document and in particular Susan Chalmers, Izumi Okutani and Wim Degezelle who jointly coordinated and supported the work on behalf of the IGF Multistakeholder Advisory Group (MAG). Regards, Marco Hogewoning -- External Relations - RIPE NCC

1 0

[training] RIPE NCC Training Courses January-March 2016
by Training Services 07 Dec '15

07 Dec '15

Dear colleagues, Our training team travels the RIPE NCC service region to deliver training courses to our members without any additional cost. Over the next few months, we'll be in Amsterdam, London, Toulouse, Prague, Baku, St. Petersburg, Helsinki, Vilnius, Chisinau, Bishkek. Visit the following page to register and to check which training courses we are giving in your area: https://lirportal.ripe.net/training/courses The RIPE NCC delivers the following training courses: - LIR Training Course - RIPE Database Training Course - Basic IPv6 Training Course - DNSSEC Training Course - 2 days Advanced IPv6 Training Course - 2 days BGP Operations and Security Training Course For more information visit: https://www.ripe.net/support/training/courses With kind regards, Rumy Spratley-Kanis Training Services Manager

1 0

first "smart" food processor with IPv6
by JORDI PALET MARTINEZ 01 Dec '15

01 Dec '15

(I hope you don’t kill me if you believe is off-topic, but I couldn’t resist) I guess this is interesting for this list (I’m not associated with the vendor) and may be a good Xmas present … if you enjoy cooking as I do ! http://www.mycook.es/mycook-touch-smart-cooking/ This food processor uses Android and is IPv6 enabled with a touch screen and WiFi connectivity. Seems to be able to do the shopping list (and actually shopping when associated shops finish their apps) for the recipes, share recipes among different users and devices, upgradable over WiFi (for firmware and recipes, of course), diet generator, news, promotions, suggestions, etc., etc. I’m testing it in the next few days ;-) I always use a Thermomix (actually use it a lot as I love cooking), and the price is about the same, 990 Euros + VAT, so the Mycook Touch it is not expensive compared with competitors (which are not “smart” neither WiFi enabled). Taurus is a well known Spanish vendor, and I think is available also in many other countries (http://taurus-home.com/en). Note: The link is only for the Spanish version, if you click on English (right now), it brings you to the older model which is not IP enabled at all. 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: Examining IPv6 Performance
by Mirjam Kuehne 26 Nov '15

26 Nov '15

Dear colleagues, For those of you who missed Geoff Huston's presentation during the IPv6 WG at RIPE 71, read it in more detail on RIPE Labs: https://labs.ripe.net/Members/gih/examining-ipv6-performance Kind regards, Mirjam Kuehne RIPE NCC

1 0

ripemtg-nat64 network at RIPE71: complain here ;)
by Jen Linkova 19 Nov '15

19 Nov '15

Hi guys, As you might have noticed there is a NAT64 SSID. This thread is for complains about that network. Please use ripemtg-nat64 SSID. Please let us know if smth goes wrong. if you have network issues while using that SSID and switching to dual-stack one fixes the problem - please reply to this thread (indeed you can create a new one, I was just thinking that keeping everything in one thread might make our life easier but I might be wrong...). -- SY, Jen Linkova aka Furry

15 29

New on RIPE Labs: Lost Stars: Why Operators Switch off IPv6
by Mirjam Kuehne 18 Nov '15

18 Nov '15

Dear colleagues, One of the measurements that we have been running for a long time is IPv6 RIPEness, where we measure the IPv6 activity of the RIPE NCC members. We award members with stars if they (for example) announce their IPv6 allocation in the global routing table. We discovered that 460 RIPE NCC members had recently stopped announcing their IPv6 prefix and asked them why. Please find the results on RIPE Labs: https://labs.ripe.net/Members/nathalie_nathalie/lost-stars-why-operators-sw… Nathalie Trenaman will present this in the IPv6 working group at RIPE 71. Kind regards, Mirjam Kuehne RIPE NCC

1 0

IPv6-only network during RIPE 71
by Ondřej Caletka 10 Nov '15

10 Nov '15

Dear WG, as the RIPE 71 approaches, I would like to revive discussion about the IPv6-only network during meeting, that has been kindly provided since RIPE 67. I think the technology is mature enough to be provided as a regular RIPE NCC service during the meeting - that means regular network name and, most important, a password that is propagated in the same way the normal Wi-Fi network password is. This is especially important for the one third of newcomers that have had a big troubles learning the password of the IPV6ONLYEXP network. After RIPE 70, I proposed a "drastic" approach [1], renaming the dual-stack meeting network to -legacy and promote the NAT64 network as the default. This is the same way they do it on FOSDEM since 2014 [2]. But maybe we could try a slow start first, keeping the dual-stacked network the default and offering the NAT64 network with some suffix like -v6only. Any ideas? -- Ondřej Caletka CESNET [1]: https://www.ripe.net/ripe/mail/archives/ipv6-wg/2015-May/002632.html [2]: https://archive.fosdem.org/2015/news/2015-01-31-ipv6-only-again/

22 38

Re: [ipv6-wg] RIPE Atlas and NAT64 (Was: IPv6-only network during RIPE 71)
by Jen Linkova 03 Nov '15

03 Nov '15

On Tue, Nov 3, 2015 at 3:18 PM, Gert Doering <gert(a)space.net> wrote: >> RIPE Atlas probe is a host. It should not care much if it's traffic is >> going via NAT64 box or not. > > Actually detecting NAT64 and flagging as such, and being able to run > tests on a group of NAT64-hidden probes might add value... I think there is a dirty hack to do it now: run a measurements from v6-enabled probes to v4-only host, check the results for the destination address they were using. But I agree, it would be nice to get a list of probes behind NAT64 w/o wasting time and credits ;) -- SY, Jen Linkova aka Furry

2 1

Re: [ipv6-wg] ipv6-wg Digest, Vol 50, Issue 3
by Timothy Roy 03 Nov '15

03 Nov '15

I agree with all on this one, It is time to rock and roll with IPV6 and as was stated earlier, if someone does not like they can choose the other one. I think it will be a boost for IPV6 (if all goes well). -----Original Message----- From: ipv6-wg [mailto:ipv6-wg-bounces@ripe.net] On Behalf Of ipv6-wg-request(a)ripe.net Sent: 03 November 2015 15:00 To: ipv6-wg(a)ripe.net Subject: ipv6-wg Digest, Vol 50, Issue 3 Send ipv6-wg mailing list submissions to ipv6-wg(a)ripe.net To subscribe or unsubscribe via the World Wide Web, visit https://www.ripe.net/mailman/listinfo/ipv6-wg or, via email, send a message with subject or body 'help' to ipv6-wg-request(a)ripe.net You can reach the person managing the list at ipv6-wg-owner(a)ripe.net When replying, please edit your Subject line so it is more specific than "Re: Contents of ipv6-wg digest..." Today's Topics: 1. Re: IPv6-only network during RIPE 71 (Sander Steffann) 2. Re: IPv6-only network during RIPE 71 (Sander Steffann) ---------------------------------------------------------------------- Message: 1 Date: Tue, 3 Nov 2015 11:54:33 +0100 From: Sander Steffann <sander(a)steffann.nl> To: Shane Kerr <shane(a)time-travellers.org> Cc: Marco Hogewoning <marcoh(a)marcoh.net>, "ipv6-wg(a)ripe.net IPv6" <ipv6-wg(a)ripe.net> Subject: Re: [ipv6-wg] IPv6-only network during RIPE 71 Message-ID: <72AAB357-AD25-4B1C-8BAC-4CC6F70836AE(a)steffann.nl> Content-Type: text/plain; charset=us-ascii Hi Shane, Op 3 nov. 2015, om 03:21 heeft Shane Kerr <shane(a)time-travellers.org> het volgende geschreven: > tl;dr Don't so cautious. Removing the "experimental" tag from IPv6 won't > ruin the RIPE meeting. +1 Well said :) Sander ------------------------------ Message: 2 Date: Tue, 3 Nov 2015 11:58:07 +0100 From: Sander Steffann <sander(a)steffann.nl> To: Philip Homburg <pch-ripeml(a)u-1.phicoh.com> Cc: "ipv6-wg(a)ripe.net IPv6" <ipv6-wg(a)ripe.net> Subject: Re: [ipv6-wg] IPv6-only network during RIPE 71 Message-ID: <C18918DD-63AC-4966-92C1-9CF78822E0FD(a)steffann.nl> Content-Type: text/plain; charset=us-ascii > (Can't wait for a request for Atlas to support NAT64, that's going to > be > interesting) Request! Cheers, Sander PS (in Dutch): iets met slapende honden wakker maken ;) End of ipv6-wg Digest, Vol 50, Issue 3 **************************************

1 0

: IGF Best Practice Forum document review “Creating an Enabling Environment for IPv6 Adoption"
by Marco Hogewoning 03 Nov '15

03 Nov '15

Dear colleagues, As mentioned in my email on 24 August, over the past few months we have been working on a project to document some high-level best practices on IPv6 adoption, titled “Creating an Enabling Environment for IPv6 Adoption.” This work is part of the Internet Governance Forum (IGF) inter-sessional efforts to create more tangible outcomes for the IGF by collecting and documenting best practices on a variety of topics. With the IGF 2015 taking place next week from 10-13 November, this project is drawing to a close and the final draft document is now published and open for review. The document is available at: http://review.intgovforum.org/?p=3987 You can use this same website to submit any comments. Comments will close on 14 November 2015, after which a final version of the document that incorporates any comments received will be released and made available for distribution. On day two of the IGF (11 November) from 09:00-10:30 local time (UTC-3) there will also be a session in which the main contributors will discuss the document and its main conclusions on what they believe are enabling factors that contribute to IPv6 adoption. Just like all sessions at the IGF, remote participation for this session will be available via http://www.intgovforum.org. Please follow the instructions that will be posted on that website. Finally I would like to thank all the RIPE community members that have contributed to this project, by responding to our survey or by making direct contributions on the mailing list or conference calls. Regards, Marco Hogewoning RIPE NCC - External Relations

1 0

New on RIPE Labs: IPv6 on the March
by Mirjam Kuehne 25 Sep '15

25 Sep '15

Dear colleagues, In this new RIPE Labs article Tony Smith from APNIC is looking at the increase in IPv6 deployment now ARIN has depleted their free pool of IPv4 addresses: https://labs.ripe.net/Members/mirjam/ipv6-on-the-march Kind regards, Mirjam Kuehne RIPE NCC

1 0

Re: [ipv6-wg] [ipv6-wg-chair] ipv6 deployment startup
by Jen Linkova 22 Sep '15

22 Sep '15

Hi Nadim, On Sat, Sep 12, 2015 at 9:59 PM, Nadim Houeiss <nadim(a)win-dsl.com> wrote: > looking to start the deployment of ipv6 only network for a new part in my > network , i need to have info about wish solution will be the best to be > used for NAT64 techniques for new ipv6 only end users will be able to reach > ipv4 different services and web servers on the web. As far as I know most network vendors (Cisco, Juniper etc) support NAT64 on their equipment. However don't forget that you'd need DNS64 as well, so I'd suggest to check if the DNS solution you are using currently supports DNS64. >From my experience the main issue is not choosing a vendor for NAT64 but dealing with broken applications: - applications which assume than "no IPv4 address" means "no Internet connectivity" and not even trying to establish any connections if the device does not receive Ipv4 address; - applications which are using IPv4 literals; - applications which ask for "A" DNS RR only, so DNS64 does not help etc. > looking forward for your reply, BTW I'm removing ipv-wg-chairs@ (as it is just an alias which is used to reach RIPE IPv6 Working group chairs) and adding RIPE IPv6 mailing list. -- SY, Jen Linkova aka Furry

2 1

[training] RIPE NCC Webinars - new dates
by Training Services 22 Sep '15

22 Sep '15

Dear colleagues, We are pleased to announce the launch of new dates for our Webinars. The RIPE NCC Webinars are live and take only one hour. You can interact with our trainers without leaving your desk. We focus on the topics and issues most important for LIRs. Register now at https://www.ripe.net/support/training/learn-online/webinars Participation is limited to 20 people, so don't hesitate if you want to take part! If you have questions, please email <training(a)ripe.net>. We look forward to seeing you online. Kind regards, RIPE NCC Training Services

1 0

[training] IP Address Space Course this November in Bucharest
by Training Services 08 Sep '15

08 Sep '15

Dear colleagues, We are happy to announce that a RIPE NCC training course will take place on the Sunday before the RIPE 71 Meeting in Bucharest this November. This course will focus on how to obtain and manage IP address space. The course is free of charge and is open to anyone interested. The course will cover the most frequently asked questions that the RIPE NCC receives about IP address space. ----------------- Course details ---------------- IPv6 Address Space Basics: How to Obtain and Manage Your IP Addresses Sunday, 15 November 2015, 10-16:00 JW Marriott Bucharest Grand Hotel ---------------- Course goals ---------------- By the end of this course, you will be able to: - Manage your IPv4 and IPv6 addresses according to current RIPE Policies - Understand how to obtain IPv4 addresses through transfers - Protect your address space from hijacking ---------------------------------------- Who will benefit from this course? ----------------------------------------- Anyone interested in the policies and procedures around address space in the RIPE NCC service region will find this course useful. No prior knowledge of the topic is necessary. ------------------------- Course outline: ------------------------- - Becoming a RIPE NCC member (why and how) - Obtaining IP addresses (IPv4 and IPv6) - IP address space transfers, mergers and acquisitions - IPv6 basics - Address space hijacking - Resource Certification (RPKI) ---------------------------- Additional information ---------------------------- - Free of charge - Coffee and lunch will be provided - Delivered by the RIPE NCC’s Training Services and Registration Services departments ----------------------------------------- Registration for RIPE NCC members ----------------------------------------- If you are a RIPE NCC member and interested in attending this course, please visit our website on the following page to register: <https://lirportal.ripe.net/training/register/courseCode/LIR20150032> ------------------------------------ Registration for non-members ------------------------------------- If you are not (yet) a member, please fill out the following information and send this to <training(a)ripe.net>: - Email: - Course name: - Full name : - Vegetarian: yes/no Be quick - we only have 45 seats available on a first come, first served basis! If there is enough interest, we will continue to offer courses on different topics of interest alongside future RIPE Meetings. Kind regards, RIPE NCC Training Services

1 0

Re: [ipv6-wg] [v6ops] Why operators filter IPv6 packets with extension headers?
by Eric Vyncke (evyncke) 08 Sep '15

08 Sep '15

Fernando et al., A couple of quick comments: - this reminds me of taylor-v6ops-fragdrop (which you cite at the end), did you approach any of this old I-D authors? - not sure whether the security implications should be re-stated again in this document, let's rather split the security & operational issues into two documents - in the introduction, 'widespread implementation limitations' is probably too strong (and I agree that my employer products could do better) - in the introduction, "intentionally dropped" ? I am afraid that some drop are not intentional - I would shorten a lot the section 3 (security implications) and simply put a lot of references to existing good documents of yours and others - I like section 4 (operational implications) but it does not match the title, it is more about why transit operators have to look at layer-4 - section 4 approaches the goal described in the abstract but actually only provide clues why operators intentionally (or non intentionally) drops packets with EH. For example, being unable to do ECMP is of course an operational impact but why would it be the cause of EH drop? - section 4.1 (iACL), beyond the permit/deny, some operators also rate limit some traffic such pings - section 4.1, perhaps worth mentioning that infrastructure ACL are more in the white list approach, i.e., what is not BGP/ICMP (in your example) to some prefixes is dropped, so, if someone uses EH to obscure the traffic, this EH traffic matching the destination prefix is dropped anyway by the ACL (so iACL works) but traffic destined to other destination is not impacted. Or did I got something wrong? - section 4.2 (route processor protection) is a little unclear - the processing of HbH would kill the Internet of course (at least with most routers), should HbH be separately called? - section 4.3 (DDoS mitigation), I am unsure about FlowSPec but can it also specify 'any traffic with EH' ? This would do the trick probably for dropping or diverting the DoS packets? - missing issue is lack of granular EH control by some routers, for example if an operator wants to block its subscribers RH-0 but can only drop RH (because RH type cannot be specified), then all RH are dropped including MIPv6 - section 5 (potential attack vector) appears to be focus on fragment drop by the public Internet. While it can probably work, the issues are twofold: 1) bad host implementations not doing enough tests before accepting a ICMP packet-too-big 2) public Internet dropping valid fragments in transit In both cases, we (the industry, vendors + operators) need to fix those two issues. May I STRONGLY suggest to remove all security issues (other docs are describing this) and focus only on the operational issues (esp in V6OPS) ? And skip any discussion on the rationale why packets with EH are dropped? Hope this helps to refine a potentially useful I-D. -éric On 1/09/15 03:17, "v6ops on behalf of Fernando Gont" <v6ops-bounces(a)ietf.org on behalf of fernando(a)gont.com.ar> wrote: >Folks, > >The topic of operators dropping IPv6 packets containing extension >headers has been raised quite a few times on this list and elsewhere. > >A month ago or so we published a document trying to summarize the >reasons for which operators filter IPv6 packets containing extension >headers. The document is available at: ><https://tools.ietf.org/id/draft-gont-v6ops-ipv6-ehs-packet-drops-00.txt> > >We're currently working on a revision of this document, and would like >to hear feedback from the working group regarding our document. e.g., > >* Did we get anything wrong? >* Is there anything missing? > >Or, if you like the document and agree with its content, that's also >interesting feedback to have. > >Thanks! > >Best regards, >-- >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 > > > >_______________________________________________ >v6ops mailing list >v6ops(a)ietf.org >https://www.ietf.org/mailman/listinfo/v6ops

4 3

Why operators filter IPv6 packets with extension headers?
by Fernando Gont 01 Sep '15

01 Sep '15

Folks, The topic of operators dropping IPv6 packets containing extension headers has been raised quite a few times on a number of mailing-lists and forums. A month ago or so we published a document trying to summarize the reasons for which operators filter IPv6 packets containing extension headers. The document is available at: <https://tools.ietf.org/id/draft-gont-v6ops-ipv6-ehs-packet-drops-00.txt> We're currently working on a revision of this document, and would like to hear feedback from the ops community regarding our document. e.g., * Did we get anything wrong? * Is there anything missing? Or, if you like the document and agree with its content, that's also interesting feedback to have. P.S.: If possible, please CC <v6ops(a)ietf.org> and <draft-gont-v6ops-ipv6-ehs-packet-drops(a)tools.ietf.org> when sending feedback. Thanks! Best regards, -- 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

1 0

[training] RIPE NCC Training Courses October-December 2015
by Training Services 27 Aug '15

27 Aug '15

Dear colleagues, Our training team travels the RIPE NCC service region to deliver training courses to our members without any additional cost. Over the next few months, we'll be in Amsterdam, Athens, Odessa, Naples, Cardiff, Barcelona, Oslo, Bucharest, Budapest, Istanbul, Zagreb, Doha, Berlin. Visit the following page to register and to check which training courses we are giving in your area: https://lirportal.ripe.net/training/courses The RIPE NCC delivers the following training courses: - LIR Training Course - RIPE Database Training Course - Basic IPv6 Training Course - 2 days Advanced IPv6 Training Course - Routing Security Training Course - DNSSEC Training Course For more information visit: https://www.ripe.net/support/training/courses With kind regards, Rumy Spratley-Kanis Training Services Manager

1 0

IGF Seeking Input: “Creating an Enabling Environment for IPv6 Adoption”
by Marco Hogewoning 24 Aug '15

24 Aug '15

Dear colleagues, As part of this year's Internet Governance Forum (IGF), an IPv6 Best Practice Forum will discuss successful approaches that encourage IPv6 adoption. To get the most out of this effort, we would like to invite you to contribute your experiences to the forum. IGF Best Practice Forums rely on input from stakeholders across the Internet community and are open to anyone who would like to contribute. The RIPE NCC and other RIRs are participating in this discussion and we hope that RIPE community members will also take part. The goal of the forum is to create a high-level document that describes successful efforts to stimulate IPv6 adoption in both the public and private sectors. An example might be the creation of a task force that coordinated to remove barriers to IPv6 adoption. The group has already created a survey aimed at IPv6 task forces, which is available here: https://goo.gl/kQhmz We would like to further invite you to share any specific examples where commercial needs were addressed, such as creating a business case to secure management support for IPv6. A dedicated public mailing list has been developed for this project, which is available here: http://mail.intgovforum.org/mailman/listinfo/bp_ipv6_intgovforum.org More information on the IGF IPv6 Best Practice Forum can be found here: http://www.intgovforum.org/cms/2008-igf-hyderabad/event-reports/78-best-pra… We invite you to contribute using the links above. If you have any questions about this effort or the IGF in general, please don’t hesitate to contact me. Kind regards Marco Hogewoning External Relations Officer RIPE NCC

1 0

Promote the use of IRC
by Daniel Baeza (Red y Sistemas TVT) 13 Aug '15

13 Aug '15

Hi all, Yesterday, I've started a discussion in the member list about promoting the use of IRC instead of Mail List for some kind of discussions, chit chat, etc. Not much members answered, but all who did said yes. The goal is to have, at least, one channel per mail list, but not limited to only that. For this list, an #ipv6 channel will be created and administrated by the WG Chairs. We want to use the actual RIPE IRC Server plus Network Services and some more irc servers linked to the Ripe one. What do you think? Regards, --Daniel

10 15

New IPv6 Tutorials Available Online
by Pedro Vaz 27 Jul '15

27 Jul '15

Dear colleagues, We are pleased to announce that two new IPv6 videos are now available as part of our growing collection of E-Learning Tutorials. You can find these here: Neighbor Discovery Protocol: https://www.ripe.net/support/training/learn-online/videos/ipv6/ipv6-fundame… 464XLAT: https://www.ripe.net/support/training/learn-online/videos/ipv6/transition-m… These videos also form part of the "Introduction to IPv6" online course that is available through the RIPE NCC Academy. If you want to join this course, you can register here: academy.ripe.net. The RIPE NCC Academy and RIPE NCC E-Learning Tutorials are a free service available to everyone. We plan to announce even more exciting E-Learning news in the coming months, so stay tuned! If you have any questions or comments, feel free to contact us at<e-learning(a)ripe.net>. Happy learning! Kind regards Pedro Vaz Trainer/Graphics Animator RIPE NCC

1 0

IPv6 martian filter-set
by Yannis Nikolopoulos 09 Jul '15

09 Jul '15

Hello, I'm not sure if people are using the fltr-martian-v6 filter set maintained by Job Snijders: filter-set: fltr-martian-v6 descr: Current IPv6 martians mp-filter: { 0000::/8^+, # loopback, unspecified, v4-mapped 0200::/7^+, # Reserved by IETF [RFC4048] 2001::/32^-, # Teredo prefix [RFC4380] 2001:db8::/32^+, # NON-ROUTABLE range to be used for documentation purpose [RFC3849] 2002::/16^-, # 6to4 prefix [RFC3068] 3ffe::/16^+, # used for the 6bone but was returned [RFC5156] 5f00::/8^+, # used for the 6bone but was returned [RFC5156] fc00::/7^+, # Unique Local Unicast [RFC4193] fe80::/10^+, # Link Local Unicast [RFC4291] fec0::/10^+, # Reserved by IETF [RFC3879] ff00::/8^+ # Multicast [RFC4291] } I'm trying to figure out why prefixes like 0200::/7 or 0400::/6 are not included in this list Any ideas? cheers, Yannis

2 2

RIPE71 IPv6 WG: call for presentations
by Jen Linkova 07 Jul '15

07 Jul '15

Dear IPv6 Enthusiasts, RIPE71 is just 4 months away and it's time to start thinking about IPv6 WG session agenda! If you would like to present, or just have any suggestions on what we should discuss) - please email ipv6-wg-chairs(a)ripe.net. If you would like to present, we need the following information: - a tentative title of your talk; - short summary - how much time you need (I'd recommend allowing 5 mins for questions). Thank you! -- SY, Jen Linkova aka Furry on behalf of IPv6 WG chairs.

1 0

Fwd: Operational Implications of IPv6 Packets with Extension (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-00.txt)
by Fernando Gont 01 Jul '15

01 Jul '15

FYI To the extent that it's possible, please discuss the I-D on the IETF v6ops mailing-list. But feel free to discuss it here anyway (I'll monitor the list for comments). Thanks! Best regards, Fernando -------- Forwarded Message -------- Subject: Operational Implications of IPv6 Packets with Extension (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-00.txt) Date: Wed, 01 Jul 2015 17:35:11 -0300 From: Fernando Gont <fgont(a)si6networks.com> To: v6ops(a)ops.ietf.org <v6ops(a)ietf.org> CC: draft-gont-v6ops-ipv6-ehs-packet-drops(a)tools.ietf.org Folks, A group of us published a new I-D trying to summarize the operational and security implications. It is meant to summarize the reasons for which operators may intentionally drop IPv6 packets containing IPv6 extension headers. The I-D is available at: <https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-drops…> As far as this I-D is concerned, think of us co-authors as the messengers. The I-D doesn't argue itself whether you should (or should not) drop packets with EHs, but simply discusses the challenge they represent in some scenarios. Comments will be more than welcome. Thanks! Best regards, Fernando -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-00.txt Date: Wed, 01 Jul 2015 13:29:21 -0700 From: internet-drafts(a)ietf.org To: Gert Doering <gert(a)space.net>, Nick Hilliard <nick(a)inex.ie>, Shucheng LIU (Will) <liushucheng(a)huawei.com>, Gert Doering <gert(a)space.net>, Warren Kumari <warren(a)kumari.net>, Will Liu (Shucheng) <liushucheng(a)huawei.com>, Fernando Gont <fgont(a)si6networks.com>, Nick Hilliard <nick(a)inex.ie>, Fernando Gont <fgont(a)si6networks.com>, Warren Kumari <warren(a)kumari.net> A new version of I-D, draft-gont-v6ops-ipv6-ehs-packet-drops-00.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-v6ops-ipv6-ehs-packet-drops Revision: 00 Title: Operational Implications of IPv6 Packets with Extension Headers Document date: 2015-07-01 Group: Individual Submission Pages: 13 URL: https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-drops… Status: https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-drops/ Htmlized: https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-00 Abstract: This document summarizes the security and operational implications of IPv6 extension headers, and attempts to analyze reasons why packets with IPv6 extension headers may be dropped in the public Internet. 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

Extension Headers / Impact on Security Devices
by Enno Rey 26 Jun '15

26 Jun '15

Hi, hope everybody had a great #RIPE70 meeting. We did! Many thanks to the organizers and chairs! With regard to the strong position on ext hdrs that I expressed in the session yesterday pls allow to add some material/sources: - this is a paper laying out how we could circumvent some major (both commercial and FOSS) IDPS solutions in their at the time of testing latest versions, by various combinations of extension headers and fragmentation: https://www.ernw.de/download/eu-14-Atlasis-Rey-Schaefer-briefings-Evasion-o…. - here's some thoughts and preliminary results of tests performed to circumvent stateless ACLs: http://www.insinuator.net/2015/01/evasion-of-cisco-acls-by-abusing-ipv6-dis…. http://www.insinuator.net/2015/01/the-persistent-problem-of-state-in-ipv6-s…. We have a (somewhat) ongoing research project looking more closely on the interaction of ACLs and extension headers. For the moment I can only state that it's not just Cisco who are "affected". More results will be available in some months. If the chairs consider this appropriate we will happily give a presentation on this stuff in Bucharest or at another occasion. We could even bring some devices to Bucharest to do some practical testing and demos "in some side room" during #RIPE71, for those interested. We can even do the latter without any official part in a session, if there's interest. As for the topic itself I'd like to summarize our position as follows: - it has not happened in the past 17 yrs (since publication of RFC2460) that compelling, Internet-scale use cases of extension headers have been brought up. - we're hence quite sceptical as for the "we might see cool use cases in 15-20 yrs" position someone expressed at the mic. - from a security perspective they turn out to be a nightmare for (a number of) current security architectures and controls. it is hence understandable (and we actually advise to do so) that they are blocked at the _border_ of networks that have not yet managed to identify a compelling use case. - looking at the "liberty" RFC2460 provides as for ext_hdrs (wrt to their number, order, options, fragmentable vs. unfragmentable part etc.) we do not expect that type of security issues to disappear soon (the main reason why we did not continue the IDPS research was that the involved student eventually delivered this thesis. one can probably find much more issues provided time & resources). Adding more parsing cycles & intelligence (read: silicon) is not an option, at least not for sth that doesn't have a use case. - the results of this (blocking) approach have been observed and documented by Jen & Fernando and others (Tim Chown). - now that "this vicious circle" has gained sufficient ground it will be even less incentivized to develop a compelling use case. which is why we do not expect to see one in the future. === Everybody have a great weekend and for those still in AMS: have a safe trip home! Best Enno -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator =======================================================

16 43

[training] RIPE NCC Webinars - new dates
by Training Services 18 Jun '15

18 Jun '15

Dear colleagues, We are pleased to announce the dates for the RIPE NCC Webinars for the coming quarter. These interactive on-line learning sessions take about one hour, and give you the opportunity to learn and interact with our trainers without leaving your desk. In the next 3 months you can participate in the following Webinars: - Advanced RIPE Atlas Usage (NEW!) - Introduction to the RIPE Database - RIPE Database - Advanced Topics - IPv6 in the RIPE Database - IPv6 Addressing Plan - Webinar for New LIRs - Resource Certification (RPKI) Register now at https://www.ripe.net/support/training/learn-online/webinars Participation is limited to 20 people, so don't hesitate if you want to take part! If you have any questions, please email <training(a)ripe.net>. We look forward to seeing you online. Kind regards, RIPE NCC Training Services

1 0

[news] Finnish IPv6 Launch Event on 8 June in Helsinki, Finland
by Marco Hogewoning 16 Jun '15

16 Jun '15

Dear colleagues, Finnish IPv6 Launch Event on 8 June in Helsinki, Finland On Tuesday 8 June, Viestintävirasto, the Finnish telecoms regulator, hosted a seminar on the launch of IPv6 in Finland across a broad spectrum of sectors. Emile Aben and I participated in this meeting on behalf of the RIPE NCC. This half-day meeting was the pinnacle of a project that started about two years ago with a renewal of the work programme of the national IPv6 task force. This renewal led to efforts to coordinate the deployment of IPv6, with the seminar date set as a milestone by which to achieve nationwide support for IPv6. The project found support from all major access providers as well as hosting companies and content providers including the national broadcaster, YLE, and MTV. We are pleased to see this strategy has paid off: the regulator estimates that approximately five million Finnish Internet connections are IPv6 enabled to date. Real-time measurements by APNIC also showed a rapid increase of IPv6 users over the preceding week: the percentage of end users observed using IPv6 quickly rose from almost nothing to 4.7%. DNA achieved the most spectacular deployment: the percentage of their customers using IPv6 skyrocketed to 16% and is still increasing. During the seminar, various operators reported on their experiences during the deployment. They also looked forward to resolving any remaining issues and using the knowledge gained to further advance IPv6 adoption throughout the country. More information about the initiative can be found at http://ipv6nyt.fi. For detailed statistics on the IPv6 deployment, see: http://stats.labs.apnic.net/ipv6/FI?c=FI&x=1&p=0&r=1&w= Regards, Marco Hogewoning -- External Relations - RIPE NCC

1 0

Re: [ipv6-wg] [v6ops] Extension Headers / Impact on Security Devices
by Mark ZZZ Smith 16 Jun '15

16 Jun '15

From: Ca By <cb.list6(a)gmail.com> To: Eric Vyncke (evyncke) <evyncke(a)cisco.com> Cc: "v6ops(a)ietf.org" <v6ops(a)ietf.org>; "ipv6-wg(a)ripe.net" <ipv6-wg(a)ripe.net> Sent: Tuesday, 16 June 2015, 8:32 Subject: Re: [v6ops] Extension Headers / Impact on Security Devices On Monday, June 15, 2015, Eric Vyncke (evyncke) <evyncke(a)cisco.com> wrote: Enno, As you probably know, Cisco handles PSIRT issues with care, so, I have no clue on this specific advisory. My own (educated) guess is that the packet causing a LC reload is fully RFC 2460 compliant but unusual, so, probably (a guess again) a combination of extension headers triggering a bug. In this specific case, I would not blame IPv6 or RFC 2460 but rather my own company (even if the affected versions were quite old as new IOS-XR versions appear to be immune to this bug). And I appreciate the humor in your rhetorical question about which FW could protect a CRS... Air gap probably :-) More generally, regarding the 'parsing of the header' and performance, my understanding (and I am NOT a HW engineer) is that there are multiple ways to parse the header chain: - purely software in low-end devices, should have a marginal performance impact - specific ASIC in middle-end devices (read high end enterprise), probably some limitations and heavy performance impact (but again within one organization, so, easier to fix the root cause) - a lot of specialized network processors in high-end devices (SP gears), which is a similar case as the 'low-end device', performance impact but marginal as parsing the chain of headers is not that hard after all _when_ coded correctly As the extension headers are specific to IPv6, this is an area when we will all learn (and have learned already) a lot of things... I respectfully disagree with your last sentence. Of course, destination AS/host SHOULD only accept useful, known and legit ext headers; but, why would an ISP filter on ext headers if they do not harm their own infra or a customer infra? Do you envision an Internet where only TCP/443 and UDP/43 would be accepted? Last point, the Internet will have to use IPv6 for 10 or 20 years at least. If the IETF/ISP block all new _options_ in _existing_ extension headers, then we will be stuck in 1997 for network innovation. While I do not like taking security risks, I even fear more the lack of innovation. I keep hearing this and it is very bizarre to hear With regards to 1997, believing that there will be innovation in the narrow waist of hour glass (network layer), that is very 1997. The network layer is stable and boring.... Hence it being narrow. Innovation is welcome everywhere except network in the e2e model / Absence of evidence is not evidence of absence. / Consider what the network and host situation was in 1997 (wired network access, desktops outselling laptops, dialup Internet for residential, corporates in total probably being the largest spenders on Internet access) to today and the near future (wireless networks, smartphones/tablets being the dominant Internet access device in some markets - and they're multi-homed, M2M/IoT considered to be place where the greatest expansion of Internet connected devices is going to occur in the near future.) / IPv6 has had relatively little adoption, and it is only starting to increase quite rapidly in the last few years and that is mainly because of mobile networks. There hasn't and still doesn't seem to be much thinking about how IPv6's differences from IPv4's can be taken advantage of yet - an "IPv4 first" or an "IPv4 == IPv6" mindset seems to be still very common (I think the network virtualisation space is where this is might be most prominent - I think most of the technologies they're inventing require fork lift network upgrades, so the costs of deploying IPv6 at the same time become a lot less significant. So if there is a "cheap" opportunity to deploy IPv6, and IPv6 is going to be the long term network layer 3, why not optimise for it now? That was the thinking behind my "Enhancing Virtual Network Encapsulation with IPv6" draft) / We don't want to disable innovation opportunities that IPv6 may provide before people have arrived at an "IPv6 first" or "IPv4 != IPv6" mindset. Let's talk on Thursday at Silvia's IPv6 Conference in Zurich ;-) -éric On 11/06/15 11:58, "Enno Rey" <erey(a)ernw.de> wrote: > >the problem here is the definition of "normal IP packet" as of RFC2460. >To illustrate this I just quote from today's Cisco advisory (Cisco IOS XR >Software Crafted IPv6 Packet Denial of Service Vulnerability) on packets >potentially crashing CRS-3 line cards: > >"The vulnerability is due to incorrect processing of an IPv6 packet >carrying IPv6 extension headers that are valid but unlikely to be seen >during normal operation. An attacker could exploit this vulnerability by >sending such an IPv6 packet to an affected device that is configured to >process IPv6 traffic. An exploit could allow the attacker to cause a >reload of the line card, resulting in a DoS condition." > >two question come to mind here: > >- is a "valid but unlikely" extension header chain "normal"? >- what ("combination of FW & IPS or whatever") would you put in front of >a CRS? > >my (sad) expectation is that we'll see much more of these (types of) >issues in the future. given the current level of freedom that the RFC2460 >leaves (see also discussion/picture in >http://www.insinuator.net/2015/06/is-ipv6-more-secure-than-ipv4-or-less/) >"properly parsing an IPv6 packet, let alone in wire speed" seems a pretty >much unsolvable task to me. > >That said I still fail to see any useful extension header besides AH&ESP >(not even FH) to be transported in the Internet. > >best > >Enno > > > > > > > > If your firewall cannot implement this policy, then >> it is time to change or to use a combination of FW & IPS or whatever. >> >> - network person: as I will live with IPv6 for the rest of my life, >>then I >> want a way to extend it and I need any packet to travel to my source to >>my >> destination. Any IPv6 packet should be able to traverse the >> Internet/private network as long as its layer-3 header is valid >> (filtering/dropping can be done exceptionally for good operational >> reason). Did we remember the IPv4 teardrop attack? It is blocked by >> default by most routers for years ;-) >> >> Bugs will plague us for ever... And make our life more complex than the >> above description of course ;-) >> >> -??ric >> >> On 17/05/15 20:43, "Silvia Hagen" <silvia.hagen(a)sunny.ch> wrote: >> >> >Hi >> > >> >I keep stumbling about that "recommendational wording" in RFC 2460 >> >everytime I teach it. >> > >> >Couldn't we update RFC2460 and make this list a strict order? >> > >> >I would want my firewall to notify me if the EHs in a packet do not >> >follow the list. >> >And limiting the number of possible EHs per packet might be a good >>idea. >> > >> >Silvia >> > >> >-----Urspr??ngliche Nachricht----- >> >Von: ipv6-wg [mailto:ipv6-wg-bounces@ripe.net] Im Auftrag von Benedikt >> >Stockebrand >> >Gesendet: Sonntag, 17. Mai 2015 18:39 >> >An: ipv6-wg(a)ripe.net >> >Betreff: Re: [ipv6-wg] Extension Headers / Impact on Security Devices >> > >> >Hi Enno and list, >> > >> >Enno Rey <erey(a)ernw.de> writes: >> > >> >> hope everybody had a great #RIPE70 meeting. We did! >> >> Many thanks to the organizers and chairs! >> > >> >and thanks to the actual speakers as well the speakers we had to turn >> >down due to time constraints, too:-) >> > >> >> If the chairs consider this appropriate we will happily give a >> >> presentation on this stuff in Bucharest or at another occasion. >> > >> >Sounds good to me! >> > >> >> - looking at the "liberty" RFC2460 provides as for ext_hdrs (wrt to >> >> their number, order[...] >> > >> >Actually, as far as I'm concerned that's the real core of the problem. >> >Or more specifically, the first two lines of RFC 2460, section 4.1: >> > >> > When more than one extension header is used in the same packet, it >>is >> > recommended that those headers appear in the following order: >> > >> >followed on the next page by >> > >> > Each extension header should occur at most once, except for the >> > Destination Options header which should occur at most twice (once >> > before a Routing header and once before the upper-layer header). >> > >> >Note in particular that these are not even RFC 2119 "SHOULD" or >> >"RECOMMENDED" and such. >> > >> >The impact here is actually at least twofold: >> > >> >- It is impossible to implement this as a simple pipeline architecture >> > in hardware; at least for cases deviating from the "recommendations" >> > above this effectively becomes either excessively complex to >>implement >> > in hardware or an invitation to DoS when implemented in software on >>an >> > otherwise hardware router. >> > >> >- As I understand it, at least some of the issues you have found are >> > effectively based on violating the second paragraph quoted, making it >> > impossible to come up with a lower bound on how long the header chain >> > can actually get and therefore leading to the fragmentation related >> > attacks and similar you have discovered. >> > >> >The original idea was that the extension headers are processed strictly >> >in the order they occur, so one question to ask is if there is any >>valid >> >reason to violate these "recommendations" for other than malicious >> >purposes. >> > >> > >> >Cheers, >> > >> > Benedikt >> > >> >-- >> >Benedikt Stockebrand, Stepladder IT >>Training+Consulting >> >Dipl.-Inform. http://www.stepladder-it.com/ >> > >> > Business Grade IPv6 --- Consulting, Training, Projects >> > >> >BIVBlog---Benedikt's IT Video Blog: >>http://www.stepladder-it.com/bivblog/ >> > >> > >> > >-- >Enno Rey > >ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de >Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 > >Handelsregister Mannheim: HRB 337135 >Geschaeftsfuehrer: Enno Rey > >======================================================= >Blog: www.insinuator.net || Conference: www.troopers.de >Twitter: @Enno_Insinuator >======================================================= > >_______________________________________________ >v6ops mailing list >v6ops(a)ietf.org >https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops(a)ietf.org https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops(a)ietf.org https://www.ietf.org/mailman/listinfo/v6ops

1 0

Looking for info on IGP choices in production dual-stack networks
by Victor Kuarsingh 09 Jun '15

09 Jun '15

RIPE IPv6 Folks: Philip Matthews and I are co-authors on an active draft within the IETF related to IPv6 routing design choices. To ensure we are gathering sufficient data we are looking for an expanded set of input from operator forums as well (vs. just the v6ops IETF list). The draft is found here -(https://tools.ietf.org/html/draft-ietf-v6ops-design-choices). We are looking for information on the IGP combinations people are running in their dual-stack networks. We are gathering this information so we can document in our draft which IGP choices are known to work well (i.e., people actually run this combination in production networks without issues). The draft will not name names, but just discuss things in aggregate: for example, "there are 3 large and 2 small production networks that run OSPF for IPv4 and IS-IS for IPv6, thus that combination is judged to work well". If you have a production dual-stack network, then we would like to know which IGP you use to route IPv4 and which you use to route IPv6. We would also like to know roughly how many routers are running this combination. Feel free to share any successes or concerns with the combination as well. We are looking particularly at combinations of the following IGPs: IS-IS, OSPFv2, OSPFv3, EIGRP. If you run something else (RIP?) then we would also like to hear about this, though we will likely document these differently. [We suspect you run RIP/RIPng only at the edge for special situations, but feel free to correct us]. And if you have one of those modern networks that carries dual-stack customer traffic in a L3VPN or similar and thus don’t need a dual-stacked core, then please email us and brag ... If you are on multiple lists at RIPE, NANOG or the IETF, we apologize for any redundant emails you may get (we are just attempting to reach the widest audience possible). Philip Matthews Victor Kuarsingh

1 0

New on RIPE Labs: IPv6 Deployment in Estonia
by Mirjam Kuehne 04 Jun '15

04 Jun '15

Dear colleagues, In case you missed Tarko Tikan's description of the IPv6 deployment in Estonia on other lists, we put the story on RIPE Labs: https://labs.ripe.net/Members/tarko_tikan/ipv6-deployment-in-estonia Kind regards, Mirjam Kuehne RIPE NCC

1 0

IPv6 only as default for next meeting
by Jérôme Fleury 24 May '15

24 May '15

During WG this afternoon, the idea was submitted that the IPv6 only experimentation be made the default SSID for the next meeting. While this has been working tremendously well for routine internet usage, I've been unable to use this network mainly because of incompatibility with my VPN network. We have a dual-stack VPN. some of the resources are v4 only though. The DNS64 converts my v4 VPN resources into v6 resources that are then routed to the non-VPN interface. While there could be workarounds (DNS64 on the VPN side, full v6 routing on the VPN, or all VPN resources available on v6) I don't think the technology is mature enough to make it the default for advanced usage. My 0.02$

11 18

How to Unsubscribe!?
by Adem Karatepe 15 May '15

15 May '15

Hi folks, I used to work in IPV6 work group before in my company and my colleague add me to this list but I'm not working on this group anymore and my colleague resigned from company so we don't have login details and we can not unsubscribe from the mail list. Is there any other way to unsubscribe? Adem Karatepe BT Proje Asistanı Project Support Staff Yazılım Geliştirme Direktörlüğü Software Development www.turksat.com.tr<http://www.turksat.com.tr> akaratepe(a)turksat.com.tr<mailto:akaratepe@turksat.com.tr> Gazi Üniversitesi Gölbaşı Yerleşkesi Teknoparkplaza kat 2 06830 Gölbaşı/ANKARA T : +90 312 497 47 00 F : +90 "Bu mesaj ve ekleri mesajda gönderildiği belirtilen kişi ya da kişilere özel olup gizli bilgiler içeriyor olabilir. Mesajın muhatabı ilgilisi ya da gönderileni değilseniz lütfen mesajı herhangi bir şekilde kullanmayınız çoğaltmayınız ve başkalarına ifşa etmeyiniz. Eğer mesaj yanlışlıkla size ulaşmışsa anılan mesaj ve ekinde yer alan bilgileri gizli tutunuz ve mesajı gönderen kişiyi bilgilendirerek söz konusu mesaj ile eklerini derhal imha ediniz. Bu mesaj ve ekindeki belgelerin bilinen virüslere karşı kontrolü yapılmıştır. Ancak e-posta sistemlerinin taşıdığı risklerden dolayı şirketimiz bu mesajın ve içerdiği bilgilerin size değişikliğe uğrayarak veya geç ulaşmasından bütünlüğünün ve gizliliğinin korunamamasından virüs içermesinden ve herhangi bir sebeple bilgisayarınıza ve sisteminize verebileceği zararlardan sorumlu tutulamaz.”<<<<< “This message together with its attachments is intended solely for the address(es) and may contain confidential or privileged information. If you are not the intended recipient please do not use copy or disclose the message for any purpose. Should you receive this message by mistake please keep all information contained in the message or its attachments strictly confidential and advise the sender and delete it immediately without retaining a copy. This message and its attachments have been swept by anti-virus systems for the presence of known viruses. However due to the risks of e-mail systems our company cannot accept liability for any changes or delay in receiving loss of integrity and confidentiality containing viruses and any damages caused in any way to your computer and system recipient, you are notified that disclosing, distributing, or copying this e-mail is strictly prohibited. “

1 0

Chair replacement procedure for ipv6-wg
by Dave Wilson 15 May '15

15 May '15

Hi all, You might remember from the last RIPE meeting that each working group had to finalise chair selection procedures. Because we were changing chairs anyway, ipv6-wg got to wait for one more meeting. Since the other working groups have gone through that process, however, we can use that to our advantage. Instead of starting from scratch, we propose to use a procedure which has already been discussed by a working group. The one we've chosen, because it seems very close to what we discussed at RIPE 69, is the procedure used by anti-abuse-wg. I hope this draft is already "good enough" for us to adopt as a result; if so, it'll save us repeating work that's already been done several times over in other WGs. We have this on the agenda for RIPE 70, and I hope we'll be able to adopt it then. Best regards, Dave ===(cut here)=== Note on Language: Throughout this document the word Chair shall be used for both Chairs and Co-Chairs. ** Introduction: This document outlines procedures dealing with the tenure of RIPE Working Group Chairs. It applies to all RIPE Working Groups. ** WG Chair Term: The term of a WG Chair is three years. A current chair may stand for re-selection at the end of their term. A WG Chair may resign voluntarily at any time. ** Selection of a WG Chair: WG Chair vacancies, along with a call for candidates, must be announced on the WG mailing list at least one month in advance of the date upon which the selection will be held. The announcement should set a closing date for candidates. A WG may request that a WG Chair vacancy be opened so long as the addition of a new Chair would not cause the number of Chairs of that WG to exceed three. WG Chairs are elected at WG sessions at RIPE meetings. Anyone physically present at the WG session is eligible to participate in the selection process. The candidate does not need to be physically present at the WG session. If possible the Chair should be elected by acclamation by the WG or by consensus after discussion. If the result is unclear, then a secret ballot should be held. In the case of a ballot, votes will be counted by RIPE NCC Staff and/or Chairs of other WGs. The result will be determined by simple majority. ** Removal of a WG Chair: A WG Chair may be unable to fulfil their duties as described in this document or otherwise fail to serve the WG and the community. With the endorsement of a significant share of the WG, a vote of no confidence may be initiated. Before a vote of no confidence is taken, due effort should be made to address the issue(s) leading to the vote. The right of reply must be given to all parties involved in the procedure. If this effort fails to resolve the issue, the vote may proceed. The vote must be requested on the WG mailing list at least one week in advance of the WG Session at a RIPE meeting and should take place during the WG session. Anyone physically present at the WG session may take part in the vote. The vote should be conducted by secret ballot and votes counted by RIPE NCC Staff and/or WG Chairs of other WGs. The result will be determined by simple majority. If the vote of no confidence in a WG Chair is passed, the seat is vacated and the WG Chair is not eligible for stand for re-selection. ** No Chair: If a working group is left with no Chair, e.g. due to the resignation or removal of the sole WG Chair, then the WG may elect an interim WG Chair according to the selection procedures specified above, but with candidates nominated at the WG session. An interim WG Chair must resign at the next WG session, but may stand for re-selection. ** Staggered Introduction: For the purposes of staggering the introduction of this policy, in the case where all co-Chairs of a WG have served for more than the standard WG Chair term limit, an optional waiver is given to these WGs to allow them to schedule the automatic resignations of their Chairs over the two RIPE meetings immediately following the adoption of this policy. If the WG decides to avail of this waiver, it is the responsibility of the WG to decide in what order its co-Chairs should stand down. ===(cut here)=== -- Dave Wilson, Service Desk Manager web: www.heanet.ie HEAnet Ltd, 5 George's Dock, IFSC, Dublin 1 tel: +353-1-660-9040 Registered in Ireland, no 275301 fax: +353-1-660-3666

5 6