From marcoh at marcoh.net Sun May 4 14:34:13 2014 From: marcoh at marcoh.net (Marco Hogewoning) Date: Sun, 4 May 2014 14:34:13 +0200 Subject: [ipv6-wg] Fwd: Updates to RIPE-500: Policy Development in RIPE References: <53662ACB.8030902@oslo.net> Message-ID: Dear Working Group, For those who are not subscribed to RIPE list, please see the following message from Hans Petter regarding updating the Policy Development Process. Feedback should be posted to RIPE list! Greetings, MarcoH Begin forwarded message: > From: Hans Petter Holen > Subject: Updates to RIPE-500: Policy Development in RIPE > Date: 4 mei 2014 13:55:55 CEST > To: ripe-list at ripe.net > > Dear colleagues, > The Working-group chairs have for some time been discussing how to improve the Policy Development Process as described in RIPE-500. A small task force with Brian Nisbet as the coordinator and Ondrej Filip, Nick Hilliard and Hans Petter Holen as members has worked out the final details in the text. > > The wg-chairs have reached consensus on the attached proposal. > > The main change in the PDP is to allow the Working-group Chairs of the working-group developing the policy to declare consensus. > > This allows for a more timely conclusion of the PDP, but also allows for the Working-group chairs collectively to act as an appeals body. > > I am circulating the new text now for community review and the intent is to put this in place at the coming RIPE meeting. > > > Yours Sincerely, > > Hans Petter Holen > RIPE Deputy Chair > -------------- next part -------------- A non-text attachment was scrubbed... Name: revised PDP_1.pdf Type: application/pdf Size: 218950 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: revised PDP_1.0.txt URL: -------------- next part -------------- > From shane at time-travellers.org Tue May 6 15:00:27 2014 From: shane at time-travellers.org (Shane Kerr) Date: Tue, 6 May 2014 15:00:27 +0200 Subject: [ipv6-wg] Draft IPv6 working group agenda for RIPE 68 ("T: -9 days" edition) Message-ID: <20140506150027.6c027c14@luna.home.time-travellers.org> IPv6 WG participants, Here's an updated version of our working group agenda. There are two changes: 1. Fixed a typo on Helge Holz's name 2. Added a talk about IPv6 Deployment at CERN by Edoardo Martelli We have two 90-minute slots in Warsaw: 2014-05-15 09:00-10:30 (Thursday 1st morning slot) 2014-05-15 11:00-12:30 (Thursday 2nd morning slot) We'll have to change rooms, but happily the slots are on the same day, so we can maintain our focus on IPv6 topics without other distractions. Our current plan: 5 minutes Session Booting & Initialization 20 minutes IPv6 Penetration in Hungary Janos Zsako 20 minutes Painting by Numbers (Visualization of Structured IPv6-Addressing) Helge Holz 15 minutes RIPE 554bis (Requirements for IPv6 in ICT Equipment... revised!) Jan Zorz / Sander Steffann 15 minutes RIPE IPv6 Analyser Alex Band 15 minutes BCOP document: "IPv6 troubleshooting procedures for helpdesks" Benno Overeinder / Jan Zorz 15 minutes IETF document: "Balanced Security for IPv6 Residential CPE" Ragnar Anfinsen 15 minutes IPv6 Campus Deployment Experience Niall O'Reilly 15 minutes IPv6 Deployment at CERN Edoardo Martelli 10 minutes Session Shutdown Slides have already started arriving for the presentations (thanks Niall!): https://ripe68.ripe.net/presentations/presentation-archive/ See you in Warsaw! On behalf of your IPv6 working group chairs, -- Shane From marcoh at marcoh.net Sun May 11 12:05:55 2014 From: marcoh at marcoh.net (Marco Hogewoning) Date: Sun, 11 May 2014 12:05:55 +0200 Subject: [ipv6-wg] IPv6 Only Testbed at RIPE68 Message-ID: Dear colleagues, Welcome to Warsaw. Following the discussion at RIPE 66, and a successful experoment in Athens last autumn, the IPv6 Working Group is happy to provide you with an experimental network that is configured to offer only IPv6. Please note this experimental network is not supported by the RIPE NCC or RIPE 68 Technical Team. We encourage everybody to connect to this network and test any websites, applications, hardware and software, and verify that they operate when an IPv4 address is no longer available. Important: This network is an experiment and is offered on a best-effort basis. We will try to maintain sufficient service levels and are happy to look into and help troubleshoot any issues you may encounter. If you rely on network connectivity for important business, we recommend you connect to the regular RIPE Meeting network. How to connect: - Make sure IPv6 is enabled on your device - Connect to SSID: IPV6ONLYEXP (5GHz) or IPVONLYEXP2.4 (2.4 GHz) - Enter the password: iknowbesteffort The network provides NAT64 translation to connect to legacy services ? please use the name server provided by the network to make use of this feature. We suggest you leave IPv4 enabled as this will be the scenario for most end users. If you have any feedback or questions please try and find me or post it to this list. Of course we also welcome any feedback during our working group sessions on Thursday. And once again big thanks to Andrew Yourtchenko, Cisco and the RIPE NCC staff who helped setting this up and provided the necessary equipment and software. Greetings, Marco Hogewoning co-chair of the IPv6 working group From tore at fud.no Mon May 12 08:57:46 2014 From: tore at fud.no (Tore Anderson) Date: Mon, 12 May 2014 08:57:46 +0200 Subject: [ipv6-wg] 464XLAT / RFC 6877 [Re: IPv6 Only Testbed at RIPE68] In-Reply-To: References: Message-ID: <537070EA.6000503@fud.no> Hi all, For those of you who are Linux users (or BSD/OS X hackers?), and happen to encounter an application or service that doesn't appear to work correctly when connected to the IPv6-only network - do try and see if 464XLAT (RFC 6877) solves the problem before giving up and connecting to the default dual-stacked network. A Linux implementation can be found here: https://github.com/toreanderson/clatd I'd appreciate any feedback, suggestions, bug reports, and so on. I'm unfortunately not in Warszawa, but I am available on IRC (nick "tore"). [1] While clatd is developed and tested only on Linux, I believe it should be possible to port it to BSD/OS X. The actual RFC 6145 packet translations is performed by TAYGA (http://www.litech.org/tayga/) and as long as TAYGA works (I've never tried, but it is available in FreeBSD ports), it ought to be possible to adapt the currently Linux-specific commands in the clatd script that set up the network environment to their BSD/OS X counterparts. Patches are welcome! (Cc: opensource-wg) Tore * Marco Hogewoning > Welcome to Warsaw. Following the discussion at RIPE 66, and a > successful experoment in Athens last autumn, the IPv6 Working Group > is happy to provide you with an experimental network that is > configured to offer only IPv6. Please note this experimental network > is not supported by the RIPE NCC or RIPE 68 Technical Team. > > We encourage everybody to connect to this network and test any > websites, applications, hardware and software, and verify that they > operate when an IPv4 address is no longer available. > > Important: This network is an experiment and is offered on a > best-effort basis. We will try to maintain sufficient service levels > and are happy to look into and help troubleshoot any issues you may > encounter. If you rely on network connectivity for important > business, we recommend you connect to the regular RIPE Meeting > network. > > How to connect: > > - Make sure IPv6 is enabled on your device > - Connect to SSID: IPV6ONLYEXP (5GHz) or IPVONLYEXP2.4 (2.4 GHz) > - Enter the password: iknowbesteffort > > The network provides NAT64 translation to connect to legacy services > ? please use the name server provided by the network to make use of > this feature. We suggest you leave IPv4 enabled as this will be the > scenario for most end users. From training at ripe.net Mon May 12 14:46:08 2014 From: training at ripe.net (Training Services) Date: Mon, 12 May 2014 14:46:08 +0200 Subject: [ipv6-wg] [training] RIPE NCC Training Courses July-September 2014 Message-ID: <5370C290.2050605@ripe.net> 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 Valencia, Tirana, Vilnius, Budapest, Tel Aviv, Samara, D?sseldorf, Stockholm, Belfast, Amsterdam, Ankara. 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 - Database Training Course - Basic IPv6 Training Course - Routing Security Training Course - 2 day Advanced Training Course - DNSSEC Training Course - Measurements Tools workshop For more information visit: http://www.ripe.net/lir-services/training/courses With kind regards, Rumy Spratley-Kanis Training Services Manager From robert.sleigh at ee.co.uk Mon May 12 18:07:42 2014 From: robert.sleigh at ee.co.uk (Sleigh, Robert) Date: Mon, 12 May 2014 16:07:42 +0000 Subject: [ipv6-wg] 464XLAT / RFC 6877 [Re: IPv6 Only Testbed at RIPE68] In-Reply-To: <537070EA.6000503@fud.no> References: <537070EA.6000503@fud.no> Message-ID: <679694A32AB94046931C676BEF4BA8B80C92575D@UK31S005EXS06.EEAD.EEINT.CO.UK> Most recent Androids (4.3 and up I think) support 464XLAT out of the box too... Regards ? Bob 07958 318592 ? Life's for sharing... and what I like to share the most is a smile -----Original Message----- From: ipv6-wg-bounces at ripe.net [mailto:ipv6-wg-bounces at ripe.net] On Behalf Of Tore Anderson Sent: 12 May 2014 07:58 To: Marco Hogewoning; ipv6-wg at ripe.net IPv6 Cc: opensource-wg at ripe.net Subject: [ipv6-wg] 464XLAT / RFC 6877 [Re: IPv6 Only Testbed at RIPE68] Hi all, For those of you who are Linux users (or BSD/OS X hackers?), and happen to encounter an application or service that doesn't appear to work correctly when connected to the IPv6-only network - do try and see if 464XLAT (RFC 6877) solves the problem before giving up and connecting to the default dual-stacked network. A Linux implementation can be found here: https://github.com/toreanderson/clatd I'd appreciate any feedback, suggestions, bug reports, and so on. I'm unfortunately not in Warszawa, but I am available on IRC (nick "tore"). [1] While clatd is developed and tested only on Linux, I believe it should be possible to port it to BSD/OS X. The actual RFC 6145 packet translations is performed by TAYGA (http://www.litech.org/tayga/) and as long as TAYGA works (I've never tried, but it is available in FreeBSD ports), it ought to be possible to adapt the currently Linux-specific commands in the clatd script that set up the network environment to their BSD/OS X counterparts. Patches are welcome! (Cc: opensource-wg) Tore * Marco Hogewoning > Welcome to Warsaw. Following the discussion at RIPE 66, and a > successful experoment in Athens last autumn, the IPv6 Working Group is > happy to provide you with an experimental network that is configured > to offer only IPv6. Please note this experimental network is not > supported by the RIPE NCC or RIPE 68 Technical Team. > > We encourage everybody to connect to this network and test any > websites, applications, hardware and software, and verify that they > operate when an IPv4 address is no longer available. > > Important: This network is an experiment and is offered on a > best-effort basis. We will try to maintain sufficient service levels > and are happy to look into and help troubleshoot any issues you may > encounter. If you rely on network connectivity for important business, > we recommend you connect to the regular RIPE Meeting network. > > How to connect: > > - Make sure IPv6 is enabled on your device > - Connect to SSID: IPV6ONLYEXP (5GHz) or IPVONLYEXP2.4 (2.4 GHz) > - Enter the password: iknowbesteffort > > The network provides NAT64 translation to connect to legacy services - > please use the name server provided by the network to make use of this > feature. We suggest you leave IPv4 enabled as this will be the > scenario for most end users. NOTICE AND DISCLAIMER This e-mail (including any attachments) is intended for the above-named person(s). If you are not the intended recipient, notify the sender immediately, delete this email from your system and do not disclose or use for any purpose. We may monitor all incoming and outgoing emails in line with current legislation. We have taken steps to ensure that this email and attachments are free from any virus, but it remains your responsibility to ensure that viruses do not adversely affect you. EE Limited Registered in England and Wales Company Registered Number: 02382161 Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9BW From david.kessens at gmail.com Wed May 14 08:02:14 2014 From: david.kessens at gmail.com (David Kessens) Date: Tue, 13 May 2014 23:02:14 -0700 Subject: [ipv6-wg] Resignation as co-chair of ipv6 Message-ID: Hi, My personal circumstances have changed in such a way that I most recently did not spent as much time and effort for the ipv6 working group as it deserves. At the same time, I have served the working group for over 15 years and it would certainly not be unreasonable to think that it is good for the working group to change direction. Considering the above, I have decided to resign as co-chair of the ipv6 working group. I hope that this change will give a chance to a new generation of RIPE participants to play a role as a chairperson of a working group and as a participant in the RIPE working group chair collective. Thanks, David Kessens --- -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Wed May 14 10:07:12 2014 From: sander at steffann.nl (Sander Steffann) Date: Wed, 14 May 2014 10:07:12 +0200 Subject: [ipv6-wg] Resignation as co-chair of ipv6 In-Reply-To: References: Message-ID: Hi David, > My personal circumstances have changed in such a way that I > most recently did not spent as much time and effort for the ipv6 > working group as it deserves. At the same time, I have served the > working group for over 15 years and it would certainly not be unreasonable > to think that it is good for the working group to change direction. > > Considering the above, I have decided to resign as co-chair of the ipv6 > working group. I hope that this change will give a chance to a new > generation of RIPE participants to play a role as a chairperson of a working > group and as a participant in the RIPE working group chair collective. Thank you for all the good work you have done for RIPE and the IPv6 WG. Sander From rogerj at gmail.com Wed May 14 10:12:40 2014 From: rogerj at gmail.com (=?UTF-8?Q?Roger_J=C3=B8rgensen?=) Date: Wed, 14 May 2014 10:12:40 +0200 Subject: [ipv6-wg] Resignation as co-chair of ipv6 In-Reply-To: References: Message-ID: On Wed, May 14, 2014 at 8:02 AM, David Kessens wrote: > Hi, > > My personal circumstances have changed in such a way that I > most recently did not spent as much time and effort for the ipv6 > working group as it deserves. At the same time, I have served the > working group for over 15 years and it would certainly not be unreasonable > to think that it is good for the working group to change direction. > > Considering the above, I have decided to resign as co-chair of the ipv6 > working group. I hope that this change will give a chance to a new > generation of RIPE participants to play a role as a chairperson of a working > group and as a participant in the RIPE working group chair collective. Thank you for the contribution over these 15years. Hope we still will see you around on meetings and active on the mailing list? -- Roger Jorgensen | ROJO9-RIPE rogerj at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From marcoh at marcoh.net Wed May 14 10:48:15 2014 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 14 May 2014 10:48:15 +0200 Subject: [ipv6-wg] Resignation as co-chair of ipv6 In-Reply-To: References: Message-ID: Dear David, Unfortunate that you could not join us here in Warsaw for a more personal farewell, I hope we still get a chance to do that at one of our upcoming meetings. Let me thank you for all your hard work you have done for this working group and the RIPE community in general. It has always been a pleasure working with you, both in my role as co-chair of this group as well as friends and colleagues over the past 15 years. Hope to see you again at our meetings and if course this mailing list. For the working group: Shane and I have been discussing this and the topic of filling this vacancy will be part of the agenda of our working group session, which will take place this Thursday. Being short notice, there will be no final decision made during this RIPE Meeting and this will be handled on the mailing list, allowing for the whole community to comment and participate in this process. Thanks, Marco Hogewoning co-chair of the RIPE IPv6 working group On 14 May 2014, at 08:02, David Kessens wrote: > Hi, > > My personal circumstances have changed in such a way that I > most recently did not spent as much time and effort for the ipv6 > working group as it deserves. At the same time, I have served the > working group for over 15 years and it would certainly not be unreasonable > to think that it is good for the working group to change direction. > > Considering the above, I have decided to resign as co-chair of the ipv6 > working group. I hope that this change will give a chance to a new > generation of RIPE participants to play a role as a chairperson of a working > group and as a participant in the RIPE working group chair collective. > > Thanks, > > David Kessens > --- From gert at space.net Wed May 14 14:37:35 2014 From: gert at space.net (Gert Doering) Date: Wed, 14 May 2014 14:37:35 +0200 Subject: [ipv6-wg] Resignation as co-chair of ipv6 In-Reply-To: References: Message-ID: <20140514123735.GA43641@Space.Net> Hi David, On Tue, May 13, 2014 at 11:02:14PM -0700, David Kessens wrote: > My personal circumstances have changed in such a way that I > most recently did not spent as much time and effort for the ipv6 > working group as it deserves. At the same time, I have served the > working group for over 15 years and it would certainly not be unreasonable > to think that it is good for the working group to change direction. Thanks for all the long years of good chairing you've done for the IPv6 WG! gert -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From Ondrej.Caletka at cesnet.cz Thu May 15 10:28:37 2014 From: Ondrej.Caletka at cesnet.cz (=?windows-1250?Q?Ond=F8ej_Caletka?=) Date: Thu, 15 May 2014 10:28:37 +0200 Subject: [ipv6-wg] 464XLAT / RFC 6877 [Re: IPv6 Only Testbed at RIPE68] In-Reply-To: <679694A32AB94046931C676BEF4BA8B80C92575D@UK31S005EXS06.EEAD.EEINT.CO.UK> References: <537070EA.6000503@fud.no> <679694A32AB94046931C676BEF4BA8B80C92575D@UK31S005EXS06.EEAD.EEINT.CO.UK> Message-ID: <53747AB5.4090600@cesnet.cz> Dne 12.5.2014 18:07, Sleigh, Robert napsal(a): > Most recent Androids (4.3 and up I think) support 464XLAT out of the box too... > They say that KitKat is running IPv6 only [1]. But according to my observations, it still does not work for Wi-Fi. Without DHCPv4, the Wi-Fi network is treated as non-working :(. [1]: https://secure.dslreports.com/shownews/TMobile-Goes-IPv6-Only-on-Android-44-Devices-126506 -- Ond?ej Caletka -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3248 bytes Desc: Elektronicky podpis S/MIME URL: From jan at go6.si Thu May 15 12:07:47 2014 From: jan at go6.si (Jan Zorz @ go6.si) Date: Thu, 15 May 2014 12:07:47 +0200 Subject: [ipv6-wg] Resignation as co-chair of ipv6 In-Reply-To: References: Message-ID: <537491F3.60600@go6.si> On 14/05/14 08:02, David Kessens wrote: > Hi, > > My personal circumstances have changed in such a way that I > most recently did not spent as much time and effort for the ipv6 > working group as it deserves. At the same time, I have served the > working group for over 15 years and it would certainly not be unreasonable > to think that it is good for the working group to change direction. > > Considering the above, I have decided to resign as co-chair of the ipv6 > working group. I hope that this change will give a chance to a new > generation of RIPE participants to play a role as a chairperson of a working > group and as a participant in the RIPE working group chair collective. David, thnx for all the good work in all this years... See you in London at RIPE69 :) Cheers, Jan From Timothy at tra.gov.om Thu May 15 12:06:14 2014 From: Timothy at tra.gov.om (Timothy Roy) Date: Thu, 15 May 2014 10:06:14 +0000 Subject: [ipv6-wg] Language smoothing Message-ID: <03C15796-8DAE-463B-AD38-454A8A6F23F5@tra.gov.om> I work for the Oman TRA, and just want to let you know that if you need English/American language smoothing in the groups docs I am willing to assist in this. Best Regards Tim Roy Sent from my iPhone From marcoh at marcoh.net Thu May 15 12:58:02 2014 From: marcoh at marcoh.net (MarcoH) Date: Thu, 15 May 2014 12:58:02 +0200 Subject: [ipv6-wg] Vacancy - nominations can go here Message-ID: <82D2713E-9B05-4C95-85CF-918D94A4DA4C@marcoh.net> Hi, As just mentioned, we are looking for new co-chairs for the IPv6 Working Group. If you need more info of what is involved feel free to ask Shane or me. We will send a more lengthy mail regarding process later. In the meantime we welcome nominations. For consistency, please reply to this thread so all nominations are grouped. MarcoH -- Sent from mobile, sorry for the typos From jan at go6.si Thu May 15 14:21:01 2014 From: jan at go6.si (Jan Zorz @ go6.si) Date: Thu, 15 May 2014 14:21:01 +0200 Subject: [ipv6-wg] Vacancy - nominations can go here In-Reply-To: <82D2713E-9B05-4C95-85CF-918D94A4DA4C@marcoh.net> References: <82D2713E-9B05-4C95-85CF-918D94A4DA4C@marcoh.net> Message-ID: <5374B12D.9050502@go6.si> On 15/05/14 12:58, MarcoH wrote: > Hi, > > As just mentioned, we are looking for new co-chairs for the IPv6 Working Group. > > If you need more info of what is involved feel free to ask Shane or me. > > We will send a more lengthy mail regarding process later. In the meantime we welcome nominations. > > For consistency, please reply to this thread so all nominations are grouped. > > MarcoH Thnx Marco. To re-state what I said on the mike during the IPv6 WG meeting: ----- I'm already a BCOP TF co-chair and I have no idea how would co-chairing two groups work, but in case of *lack* of good candidates I suspect we might make it work somehow and I could also serve as a co-chair of IPv6 WG - but please consider other better candidates/volunteers first. ----- Cheers, Jan Zorz From furry13 at gmail.com Thu May 15 14:36:25 2014 From: furry13 at gmail.com (Jen Linkova) Date: Thu, 15 May 2014 14:36:25 +0200 Subject: [ipv6-wg] Vacancy - nominations can go here In-Reply-To: <82D2713E-9B05-4C95-85CF-918D94A4DA4C@marcoh.net> References: <82D2713E-9B05-4C95-85CF-918D94A4DA4C@marcoh.net> Message-ID: Thanks Marco for starting the thread! I'd like to volunteer for this role and I'd be happy to do my best to help the WG, the community and the global IPv6 deployment ;) On Thu, May 15, 2014 at 12:58 PM, MarcoH wrote: > Hi, > > As just mentioned, we are looking for new co-chairs for the IPv6 Working Group. > > If you need more info of what is involved feel free to ask Shane or me. > > We will send a more lengthy mail regarding process later. In the meantime we welcome nominations. > > For consistency, please reply to this thread so all nominations are grouped. > > MarcoH > -- > Sent from mobile, sorry for the typos -- SY, Jen Linkova aka Furry From kuenzler at init7.net Thu May 15 14:37:16 2014 From: kuenzler at init7.net (Fredy Kuenzler) Date: Thu, 15 May 2014 14:37:16 +0200 Subject: [ipv6-wg] Vacancy - nominations can go here In-Reply-To: <5374B12D.9050502@go6.si> References: <82D2713E-9B05-4C95-85CF-918D94A4DA4C@marcoh.net> <5374B12D.9050502@go6.si> Message-ID: <5374B4FC.7010609@init7.net> Jan, we want you! Jan, we want you! Jan, we want you! Jan, we want you! Jan, we want you! Jan, we want you! Jan, we want you! [Crowd shouting your name with big noise and screaming and an drummer giving the beat via stadium sized speakers] No choice. Sorry. :-P F. Am 15.05.2014 14:21, schrieb Jan Zorz @ go6.si: > On 15/05/14 12:58, MarcoH wrote: >> Hi, >> >> As just mentioned, we are looking for new co-chairs for the IPv6 >> Working Group. >> >> If you need more info of what is involved feel free to ask Shane or >> me. >> >> We will send a more lengthy mail regarding process later. In the >> meantime we welcome nominations. >> >> For consistency, please reply to this thread so all nominations >> are grouped. >> >> MarcoH > Thnx Marco. > > To re-state what I said on the mike during the IPv6 WG meeting: > ----- > I'm already a BCOP TF co-chair and I have no idea how would > co-chairing two groups work, but in case of *lack* of good candidates > I suspect we might make it work somehow and I could also serve as a > co-chair of IPv6 WG - but please consider other better > candidates/volunteers first. > ----- > > Cheers, Jan Zorz -- Fredy Kuenzler Init7 (Switzerland) Ltd. AS13030 St. Georgen-Strasse 70 CH-8400 Winterthur Skype: flyingpotato Phone: +41 44 315 4400 Fax: +41 44 315 4401 Twitter: @init7 / @kuenzler http://www.init7.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 553 bytes Desc: OpenPGP digital signature URL: From sander at steffann.nl Thu May 15 15:45:36 2014 From: sander at steffann.nl (Sander Steffann) Date: Thu, 15 May 2014 15:45:36 +0200 Subject: [ipv6-wg] Vacancy - nominations can go here In-Reply-To: <5374B12D.9050502@go6.si> References: <82D2713E-9B05-4C95-85CF-918D94A4DA4C@marcoh.net> <5374B12D.9050502@go6.si> Message-ID: Hi Jan, > To re-state what I said on the mike during the IPv6 WG meeting: > ----- > I'm already a BCOP TF co-chair and I have no idea how would co-chairing two groups work, but in case of *lack* of good candidates I suspect we might make it work somehow and I could also serve as a co-chair of IPv6 WG - but please consider other better candidates/volunteers first. > ----- You already doing ISOC, Go6.si, RIPE PC, RIPE BCOP, working on RIPE-554bis, working on the IPv6 document for helpdesks and probably so many other wonderful things to promote IPv6. Make sure you can handle the workload. We don't want to lose you because of burnout! ;-) Cheers, and thank you for making so much your scarce time available to this community! Sander From bs at stepladder-it.com Thu May 15 16:28:32 2014 From: bs at stepladder-it.com (Benedikt Stockebrand) Date: Thu, 15 May 2014 14:28:32 +0000 Subject: [ipv6-wg] Follow-Up on Niall's talk: Ramond (RA Monitoring Daemon) Message-ID: <877g5n3ylr.fsf@stepladder-it.com> Hi folks, after his presentation learned from Niall that he didn't actually know about the ramond, so here's some quick info for all who have a similar situation like him: Ramond is a little tool that listens for RAs and then matches the source MAC address or whatever with a list of authorized routers. It can clean up after rogue router RAs by sending a follow-up RA with router lifetime of 0 and deprecating all the advertised prefixes, and it can also run some external programs/scripts to do additional clean up (like an automated retaliation strike). It's open source and should run on all standard Unixes (so far I've only tested it on Linux myself), and of course it can be combined with 802.1Q. I've also covered it in the second half of my video blog episode at http://www.stepladder-it.com/bivblog/23 with the most relevant parts starting at about 15:00 into the video. If you handle networks with a potential for rogue advertising routers and don't know about the tool, I recommend you take a look at it. 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/ From bs at stepladder-it.com Thu May 15 16:46:56 2014 From: bs at stepladder-it.com (Benedikt Stockebrand) Date: Thu, 15 May 2014 14:46:56 +0000 Subject: [ipv6-wg] Vacancy - nominations can go here In-Reply-To: <82D2713E-9B05-4C95-85CF-918D94A4DA4C@marcoh.net> (marcoh@marcoh.net's message of "Thu, 15 May 2014 12:58:02 +0200") References: <82D2713E-9B05-4C95-85CF-918D94A4DA4C@marcoh.net> Message-ID: <87tx8r2j6n.fsf@stepladder-it.com> Hi again, after Shane, and to some degree Sander, convinced me that my not-so-ISP background might actually be useful, I volunteer too---on the condition that this is for the IPv6 working group only and *not* for address policy or cooperation or so:-) 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/ From dave.wilson at heanet.ie Thu May 15 16:53:57 2014 From: dave.wilson at heanet.ie (Dave Wilson) Date: Thu, 15 May 2014 15:53:57 +0100 Subject: [ipv6-wg] Vacancy - nominations can go here In-Reply-To: <82D2713E-9B05-4C95-85CF-918D94A4DA4C@marcoh.net> References: <82D2713E-9B05-4C95-85CF-918D94A4DA4C@marcoh.net> Message-ID: <5374D505.20704@heanet.ie> Thanks, Marco! Yourself, Shane and David have kept this WG in such good order - I'll also be delighted to help if I can. Best regards, Dave -- Dave Wilson, Project 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 From erey at ernw.de Thu May 15 17:53:56 2014 From: erey at ernw.de (Enno Rey) Date: Thu, 15 May 2014 17:53:56 +0200 Subject: [ipv6-wg] Follow-Up on Niall's talk: Ramond (RA Monitoring Daemon) In-Reply-To: <877g5n3ylr.fsf@stepladder-it.com> References: <877g5n3ylr.fsf@stepladder-it.com> Message-ID: <20140515155356.GD1054@ernw.de> Benedikt, thanks for that info; seems like an interesting tool. Still, some comments here: On Thu, May 15, 2014 at 02:28:32PM +0000, Benedikt Stockebrand wrote: > Hi folks, > > after his presentation learned from Niall that he didn't actually know > about the ramond, so here's some quick info for all who have a similar > situation like him: > > Ramond is a little tool that listens for RAs and then matches the source > MAC address or whatever with a list of authorized routers. given current attacks tools (both fake_router from THC-IPV6 and ra6 from the SI6 Networks' toolkit) can easily send packets with spoofed source MAC address, such a tool+list doesn't really help against a "skilled & motivated attacker". It would help against accidentally brought-in/fired-up systems emitting rogue RAs (which, admittedly, in quite some networks constitute a bigger risk than said attacker) but that threat/risk can easily be addressed with stuff like "router-preference high" (or its equivalents) on the infrastructure side. and this type of stuff/mitigation is available to _most_ networks in the interim. more importantly I'd like to ask you another question: how many environments do you know which have a "mature network incident response process" which would have to be followed once ramond "alerts $ADMIN of $VIOLATION"? unfortunately there's usually a strong correlation between "lack of appropriate tools" and "lack of process maturity" so those environments where ramond could make sense will not be able to make reasonable use of it anyway. In general, the "detection/reaction type of tools" (as opposed to a "prevention-oriented" security approach) haven't proven their usefullness too much in the past. best Enno It can clean > up after rogue router RAs by sending a follow-up RA with router lifetime > of 0 and deprecating all the advertised prefixes, and it can also run > some external programs/scripts to do additional clean up (like an > automated retaliation strike). It's open source and should run on all > standard Unixes (so far I've only tested it on Linux myself), and of > course it can be combined with 802.1Q. > > I've also covered it in the second half of my video blog episode at > http://www.stepladder-it.com/bivblog/23 with the most relevant parts > starting at about 15:00 into the video. > > If you handle networks with a potential for rogue advertising routers > and don't know about the tool, I recommend you take a look at it. > > > 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 ======================================================= From postdienste at datev.de Thu May 15 18:28:28 2014 From: postdienste at datev.de (Cudok, Dr. Andreas) Date: Thu, 15 May 2014 18:28:28 +0200 Subject: [ipv6-wg] Discrepancies within ripe-554 Message-ID: <2AA8F6DDEF954D548CBABACC602CC619@adsec.datev.de> Dear Sirs, while reading ripe-554 (http://www.ripe.net/ripe/docs/ripe-554) carefully, I found the following discrepancies: 1. In section "Requirements for network security equipment" you say that "For every mandatory standard the applicable subgroups are specified in parentheses at the end of the line". Then within "Mandatory Support" you can find the following line: "Deprecation of Type 0 Routing Headers in IPv6 [RFC5095]*". Does the omission of any applicable subgroup mean, that this requirement is not applicable to any subgroup (where the "*" just indicates that this is a requirement for "IPv6 Ready Logo" only), or does it in contrast mean, that this requirement is implicitly applicable to all 3 subgroups FW, IFS and APFW? 2. Within "Optional Support" of section "Requirements for network security equipment" with one exception no applicable subgroups are specified. Does this mean, that these optional requirements are implicitly applicable to all 3 subgroups FW, IFS and APFW? But then no applicable subgroup should be mentioned at all, hence the one exception I mentioned causes confusion: "Using IPsec to Secure IPv6-in-IPv4 Tunnels [RFC4891] (FW)". And you are embarrassed even more when you see the following a few lines later: "Using IPSec to Secure IPv6-in-IPv4 Tunnels [RFC4891]". Hence, I assume that the first line "Using IPsec to Secure IPv6-in-IPv4 Tunnels [RFC4891] (FW)" is an error and has to be wiped out? 3. Within "Mandatory Support" of section "Requirements for network security equipment" you find "If the request is for a dynamic internal gateway protocol (IGP), then the required . , OSPF-v3 [RFC5340] . must be supported." while within "Optional Support" of section "Requirements for network security equipment" you will see: "OSPF-v3 [RFC5340]". Can you explain this contrariety? 4. Within "Mandatory Support" of section "Requirements for network security equipment" you find "If OSPF-v3 is requested, the device must support "Authentication/Confidentiality for OSPFv3" [RFC4552] (FW, IPS, APFW)" while within "Optional Support" of section "Requirements for network security equipment" you will see: "Authentication/Confidentiality for OSPF-v3 [RFC4552]". Can you explain this contrariety? Your answers are welcome! Kind Regards DATEV eG Dr. Andreas Cudok Paumgartnerstr. 6-14 D 90329 N?rnberg Phone +49(911)319-4031 Mail andreas.cudok at datev.de _____ Diese E-Mail wurde mit einem Zertifikat der DATEV eG signiert. Damit k?nnen Sie sicher sein, dass die Nachricht so von uns gesendet wurde. Wenn Sie eine Meldung erhalten, dass die Signatur ung?ltig ist oder nicht gepr?ft werdenkann, fehlt das Zertifikat zu dieser Signatur auf Ihrem Rechner. Informationen zu Zertifikaten und zur digitalen Signatur finden Sie unter www.datev.de/zertifikate im Internet. _____ DATEV eG 90329 N?rnberg Sitz: 90429 N?rnberg, Paumgartnerstra?e 6-14 Registergericht N?rnberg, GenReg Nr. 70 Telefon +49 911 319-0 Telefax +49 911 319-3196 E-Mail info at datev.de Internet www.datev.de Vorstand Prof. Dieter Kempf (Vorsitzender) Dipl.-Kfm. Wolfgang Stegmann (stellvertretender Vorsitzender) Dipl.-Kfm. Dr. Robert Mayr J?rg Rabe v. Pappenheim Dipl.-Vw. Eckhard Schwarzer Vorsitzender des Aufsichtsrates: Reinhard Verholen -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: vCard.vcf Type: text/x-vcard Size: 2208 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 1996 bytes Desc: not available URL: From tjc at ecs.soton.ac.uk Thu May 15 20:45:08 2014 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Thu, 15 May 2014 19:45:08 +0100 Subject: [ipv6-wg] Follow-Up on Niall's talk: Ramond (RA Monitoring Daemon) In-Reply-To: <20140515155356.GD1054@ernw.de> References: <877g5n3ylr.fsf@stepladder-it.com> <20140515155356.GD1054@ernw.de> Message-ID: Hi, On 15 May 2014, at 16:53, Enno Rey wrote: > Benedikt, > > thanks for that info; seems like an interesting tool. > Still, some comments here: > > On Thu, May 15, 2014 at 02:28:32PM +0000, Benedikt Stockebrand wrote: >> Hi folks, >> >> after his presentation learned from Niall that he didn't actually know >> about the ramond, so here's some quick info for all who have a similar >> situation like him: >> >> Ramond is a little tool that listens for RAs and then matches the source >> MAC address or whatever with a list of authorized routers. > > given current attacks tools (both fake_router from THC-IPV6 and ra6 from the SI6 Networks' toolkit) can easily send packets with spoofed source MAC address, such a tool+list doesn't really help against a "skilled & motivated attacker". It would help against accidentally brought-in/fired-up systems emitting rogue RAs (which, admittedly, in quite some networks constitute a bigger risk than said attacker) but that threat/risk can easily be addressed with stuff like "router-preference high" (or its equivalents) on the infrastructure side. and this type of stuff/mitigation is available to _most_ networks in the interim. > > more importantly I'd like to ask you another question: how many environments do you know which have a "mature network incident response process" which would have to be followed once ramond "alerts $ADMIN of $VIOLATION"? unfortunately there's usually a strong correlation between "lack of appropriate tools" and "lack of process maturity" so those environments where ramond could make sense will not be able to make reasonable use of it anyway. > > In general, the "detection/reaction type of tools" (as opposed to a "prevention-oriented" security approach) haven't proven their usefullness too much in the past. The reason we knocked up RAmond was to handle accidental rogue RAs, usually caused by Windows ICS at the time. I think we saw that over the course of a year there was a rogue RA somewhere on our WLAN around 50% of the time. So I would say it was very useful, for that type of incident. This was around the time RFC6104 was in its first draft state. Tim > > best > > Enno > > > > > > > > > > > It can clean >> up after rogue router RAs by sending a follow-up RA with router lifetime >> of 0 and deprecating all the advertised prefixes, and it can also run >> some external programs/scripts to do additional clean up (like an >> automated retaliation strike). It's open source and should run on all >> standard Unixes (so far I've only tested it on Linux myself), and of >> course it can be combined with 802.1Q. >> >> I've also covered it in the second half of my video blog episode at >> http://www.stepladder-it.com/bivblog/23 with the most relevant parts >> starting at about 15:00 into the video. >> >> If you handle networks with a potential for rogue advertising routers >> and don't know about the tool, I recommend you take a look at it. >> >> >> 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 > ======================================================= > From fgont at si6networks.com Thu May 15 20:33:20 2014 From: fgont at si6networks.com (Fernando Gont) Date: Thu, 15 May 2014 13:33:20 -0500 Subject: [ipv6-wg] Follow-Up on Niall's talk: Ramond (RA Monitoring Daemon) In-Reply-To: <20140515155356.GD1054@ernw.de> References: <877g5n3ylr.fsf@stepladder-it.com> <20140515155356.GD1054@ernw.de> Message-ID: <53750870.8010502@si6networks.com> On 05/15/2014 10:53 AM, Enno Rey wrote: > > given current attacks tools (both fake_router from THC-IPV6 and ra6 > from the SI6 Networks' toolkit) can easily send packets with spoofed > source MAC address, such a tool+list doesn't really help against a > "skilled & motivated attacker". [....] > > In general, the "detection/reaction type of tools" (as opposed to a > "prevention-oriented" security approach) haven't proven their > usefullness too much in the past. FWIW, I agee with Enno here. Besides, an attacker can always send more packets to counter the ramond' "problem solving" packets. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont at si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont at si6networks.com Fri May 16 02:09:34 2014 From: fgont at si6networks.com (Fernando Gont) Date: Thu, 15 May 2014 19:09:34 -0500 Subject: [ipv6-wg] Follow-Up on Niall's talk: Ramond (RA Monitoring Daemon) In-Reply-To: References: <877g5n3ylr.fsf@stepladder-it.com> <20140515155356.GD1054@ernw.de> Message-ID: <5375573E.9020603@si6networks.com> On 05/15/2014 01:45 PM, Tim Chown wrote: >> >> In general, the "detection/reaction type of tools" (as opposed to a >> "prevention-oriented" security approach) haven't proven their >> usefullness too much in the past. > > The reason we knocked up RAmond was to handle accidental rogue RAs, > usually caused by Windows ICS at the time. I think we saw that over > the course of a year there was a rogue RA somewhere on our WLAN > around 50% of the time. So I would say it was very useful, for that > type of incident. Agreed. It's certainly useful for the non-attack case. -- Fernando Gont SI6 Networks e-mail: fgont at si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From marcoh at marcoh.net Fri May 16 11:46:34 2014 From: marcoh at marcoh.net (MarcoH) Date: Fri, 16 May 2014 11:46:34 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 Message-ID: <6F0271D3-D319-4ED4-B973-62EA75B019C0@marcoh.net> Hello, First of all let me use this opportunity to say thank you to Andrew Yourtchenko and the RIPE NCC staff for all their support and work in making this available. Statistics show that again quite a lot of people have used or at least tried this network. A few issues bubbled up, but they were all related to issues with 3rd party software and one minor incident with the layer 2 infrastructure that was not related to our specific setup. Please feel free to give feedback about this experiment on this list. But also please consider relaying it back to the developers or companies and compliment with a nice job done or ask them to fix any bugs you may have encountered. Thanks, MarcoH -- Sent from mobile, sorry for the typos From zbynek at dialtelecom.cz Fri May 16 12:00:34 2014 From: zbynek at dialtelecom.cz (Zbynek Pospichal) Date: Fri, 16 May 2014 12:00:34 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: <6F0271D3-D319-4ED4-B973-62EA75B019C0@marcoh.net> References: <6F0271D3-D319-4ED4-B973-62EA75B019C0@marcoh.net> Message-ID: <5375E1C2.6050803@dialtelecom.cz> Hi, I have to say it has been working great, except some trouble with 6->4 translation which was not 100 % for any application. Although thanks for such test... But, just my two cents: maybe you can use next time IPv6 only network without any translation to show to anyone all the services which are still v4 only. BR, Zbynek Dne 16.05.14 11:46, MarcoH napsal(a): > Hello, > > First of all let me use this opportunity to say thank you to Andrew Yourtchenko and the RIPE NCC staff for all their support and work in making this available. > > Statistics show that again quite a lot of people have used or at least tried this network. > > A few issues bubbled up, but they were all related to issues with 3rd party software and one minor incident with the layer 2 infrastructure that was not related to our specific setup. > > Please feel free to give feedback about this experiment on this list. But also please consider relaying it back to the developers or companies and compliment with a nice job done or ask them to fix any bugs you may have encountered. > > Thanks, > > MarcoH > From ayourtch at gmail.com Fri May 16 14:44:29 2014 From: ayourtch at gmail.com (=?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?=) Date: Fri, 16 May 2014 14:44:29 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: <5375E1C2.6050803@dialtelecom.cz> References: <6F0271D3-D319-4ED4-B973-62EA75B019C0@marcoh.net> <5375E1C2.6050803@dialtelecom.cz> Message-ID: Zbynek, The choice for having a NAT64 was to provide a more gentle headstart, since a NAT64 has a strictly bigger set of apps/sites that do work. And, we felt that we should tread lightly - maximize the potential of actually using the v6only as a "business as usual" SSID. The "true IPv6-only" was a DNS server address away: e.g. you could temporarily hardcode the 2001:4860:4860::8888 for the tests, instead of the DNS64 local resolver address. But would be very interesting to hear from the community, what would people think is the most useful option to do ? --a On 5/16/14, Zbynek Pospichal wrote: > Hi, > > I have to say it has been working great, except some trouble with 6->4 > translation which was not 100 % for any application. Although thanks for > such test... > > But, just my two cents: maybe you can use next time IPv6 only network > without any translation to show to anyone all the services which are > still v4 only. > > BR, > Zbynek > > > Dne 16.05.14 11:46, MarcoH napsal(a): >> Hello, >> >> First of all let me use this opportunity to say thank you to Andrew >> Yourtchenko and the RIPE NCC staff for all their support and work in >> making this available. >> >> Statistics show that again quite a lot of people have used or at least >> tried this network. >> >> A few issues bubbled up, but they were all related to issues with 3rd >> party software and one minor incident with the layer 2 infrastructure that >> was not related to our specific setup. >> >> Please feel free to give feedback about this experiment on this list. But >> also please consider relaying it back to the developers or companies and >> compliment with a nice job done or ask them to fix any bugs you may have >> encountered. >> >> Thanks, >> >> MarcoH >> > > > From list-ripe-ipv6-wg at dragon.net Fri May 16 15:02:58 2014 From: list-ripe-ipv6-wg at dragon.net (Paul Ebersman) Date: Fri, 16 May 2014 07:02:58 -0600 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: References: <6F0271D3-D319-4ED4-B973-62EA75B019C0@marcoh.net> <5375E1C2.6050803@dialtelecom.cz> Message-ID: <20140516130258.E34CA377091A@fafnir.remote.dragon.net> ayourtch> The choice for having a NAT64 was to provide a more gentle ayourtch> headstart, since a NAT64 has a strictly bigger set of ayourtch> apps/sites that do work. And, we felt that we should tread ayourtch> lightly - maximize the potential of actually using the v6only ayourtch> as a "business as usual" SSID. ayourtch> The "true IPv6-only" was a DNS server address away: e.g. you ayourtch> could temporarily hardcode the 2001:4860:4860::8888 for the ayourtch> tests, instead of the DNS64 local resolver address. I think that going for the most usable user experience (even if we have to do transition technologies for now) is best. However, I like the idea of having an IPv6 DNS server that isn't doing DNS64 that you can hard code if you want the true v6-only, no NAT experience. From nicolas at ncartron.org Fri May 16 15:09:05 2014 From: nicolas at ncartron.org (Nicolas CARTRON) Date: Fri, 16 May 2014 15:09:05 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: References: <6F0271D3-D319-4ED4-B973-62EA75B019C0@marcoh.net> <5375E1C2.6050803@dialtelecom.cz> Message-ID: On Fri, May 16, 2014 at 2:44 PM, Andrew ? Yourtchenko wrote: > Zbynek, > > The choice for having a NAT64 was to provide a more gentle headstart, > since a NAT64 has a strictly bigger set of apps/sites that do work. > And, we felt that we should tread lightly - maximize the potential of > actually using the v6only as a "business as usual" SSID. > > The "true IPv6-only" was a DNS server address away: e.g. you could > temporarily hardcode the 2001:4860:4860::8888 for the tests, instead > of the DNS64 local resolver address. > > But would be very interesting to hear from the community, what would > people think is the most useful option to do ? Fully agreed with Zbynek, having a v6-only network would be interesting as well. -- Nicolas -------------- next part -------------- An HTML attachment was scrubbed... URL: From niall.oreilly at ucd.ie Fri May 16 15:18:14 2014 From: niall.oreilly at ucd.ie (Niall O'Reilly) Date: Fri, 16 May 2014 15:18:14 +0200 Subject: [ipv6-wg] Follow-Up on Niall's talk: Ramond (RA Monitoring Daemon) In-Reply-To: <877g5n3ylr.fsf@stepladder-it.com> References: <877g5n3ylr.fsf@stepladder-it.com> Message-ID: At Thu, 15 May 2014 14:28:32 +0000, Benedikt Stockebrand wrote: > > Hi folks, > > after his presentation learned from Niall that he didn't actually know > about the ramond, so here's some quick info for all who have a similar > situation like him: > > Ramond is a little tool that listens for RAs and then matches the source > MAC address or whatever with a list of authorized routers. Thanks again, Benedikt, for making me aware of this tool. The problem it addresses seems to be parallel to the one which has my main attention at the moment. I need to track NAs (including legitimate ones) rather than RAs. So far, I'm aware of the following two potential solutions whose trails seem worth following to find out more: https://nav.uninett.no/wiki/navfaq https://6mon.iit.cnr.it/ I'll be glad to learn of others. ATB, Niall From niall.oreilly at ucd.ie Fri May 16 16:20:29 2014 From: niall.oreilly at ucd.ie (Niall O'Reilly) Date: Fri, 16 May 2014 16:20:29 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: <20140516130258.E34CA377091A@fafnir.remote.dragon.net> References: <6F0271D3-D319-4ED4-B973-62EA75B019C0@marcoh.net> <5375E1C2.6050803@dialtelecom.cz> <20140516130258.E34CA377091A@fafnir.remote.dragon.net> Message-ID: At Fri, 16 May 2014 07:02:58 -0600, Paul Ebersman wrote: > > [...] However, I like the idea > of having an IPv6 DNS server that isn't doing DNS64 that you can hard > code if you want the true v6-only, no NAT experience. Something for the interested to configure manually, or yet another SSID/WLAN with stateless DHCPv6 to signal the (IPv6-only) set of resolver addresses? I think I'ld go for the latter, so as to provide a "shrink-wrapped" service. /Niall From furry13 at gmail.com Fri May 16 16:24:56 2014 From: furry13 at gmail.com (Jen Linkova) Date: Fri, 16 May 2014 16:24:56 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: <6F0271D3-D319-4ED4-B973-62EA75B019C0@marcoh.net> References: <6F0271D3-D319-4ED4-B973-62EA75B019C0@marcoh.net> Message-ID: Thanks for organizing it, it just worked ;) What would be really awesome is to stop announcing that network as 'an experiment'. My understanding is that we need 1) [hardest part] get smth better than 'best effort' support level; 2) change the password from 'iknowbesteffort' 3) stop calling it 'experimental' in public 4) tell people that if smth does not work they should fall back to the 'standard' network and see if it helps. I'm not suggesting making it a default network at the current stage but I think that it is mature enough to move out of 'experimental' phase. We could call it 'pilot', 'canary' or '1st phase of rollout' ;) On Fri, May 16, 2014 at 11:46 AM, MarcoH wrote: > Hello, > > First of all let me use this opportunity to say thank you to Andrew Yourtchenko and the RIPE NCC staff for all their support and work in making this available. > > Statistics show that again quite a lot of people have used or at least tried this network. > > A few issues bubbled up, but they were all related to issues with 3rd party software and one minor incident with the layer 2 infrastructure that was not related to our specific setup. > > Please feel free to give feedback about this experiment on this list. But also please consider relaying it back to the developers or companies and compliment with a nice job done or ask them to fix any bugs you may have encountered. > > Thanks, > > MarcoH > -- > Sent from mobile, sorry for the typos -- SY, Jen Linkova aka Furry From list-ripe-ipv6-wg at dragon.net Fri May 16 16:30:21 2014 From: list-ripe-ipv6-wg at dragon.net (Paul Ebersman) Date: Fri, 16 May 2014 08:30:21 -0600 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: References: <6F0271D3-D319-4ED4-B973-62EA75B019C0@marcoh.net> <5375E1C2.6050803@dialtelecom.cz> <20140516130258.E34CA377091A@fafnir.remote.dragon.net> Message-ID: <20140516143021.678473772371@fafnir.remote.dragon.net> pebersman> However, I like the idea of having an IPv6 DNS server that pebersman> isn't doing DNS64 that you can hard code if you want the true pebersman> v6-only, no NAT experience. niall> Something for the interested to configure manually, or yet niall> another SSID/WLAN with stateless DHCPv6 to signal the (IPv6-only) niall> set of resolver addresses? I'd be OK with either. My opinion, it's up to the folks running the network to say which will be less of a pain to do. From erey at ernw.de Fri May 16 17:38:00 2014 From: erey at ernw.de (Enno Rey) Date: Fri, 16 May 2014 17:38:00 +0200 Subject: [ipv6-wg] Follow-Up on Niall's talk: Ramond (RA Monitoring Daemon) In-Reply-To: References: <877g5n3ylr.fsf@stepladder-it.com> Message-ID: <20140516153800.GH10353@ernw.de> Niall, On Fri, May 16, 2014 at 03:18:14PM +0200, Niall O'Reilly wrote: > > The problem it addresses seems to be parallel to the one which has my > main attention at the moment. I need to track NAs (including legitimate > ones) rather than RAs. > > So far, I'm aware of the following two potential solutions whose trails > seem worth following to find out more: > > https://nav.uninett.no/wiki/navfaq > https://6mon.iit.cnr.it/ > > I'll be glad to learn of others. tools that work similarly to ramond (monitoring the local link as opposed to infrastructure-based), but do so for NAs, include: ipv6mon (http://www.si6networks.com/tools/ipv6mon/), NDPmon (http://ndpmon.sourceforge.net/). not sure about your use case, but you might furthermore find this post helpful: http://blog.webernetz.net/2014/03/17/monitoring-mac-ipv6-address-bindings/ Crossposting to IPv6hackers mailing list as guys over there might have other/better suggestions. apologies in advance for this! have a great weekend everybody Enno > > ATB, > Niall > -- 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 ======================================================= From modonovan at btireland.net Fri May 16 22:15:02 2014 From: modonovan at btireland.net (Mick O'Donovan) Date: Fri, 16 May 2014 21:15:02 +0100 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: References: <6F0271D3-D319-4ED4-B973-62EA75B019C0@marcoh.net> Message-ID: On 16 May 2014, at 15:24, Jen Linkova wrote: > Thanks for organizing it, it just worked ;) > Ditto - I was very keen to getting using it so thanks again. > What would be really awesome is to stop announcing that network as 'an > experiment'. My understanding is that we need > 1) [hardest part] get smth better than 'best effort' support level; > 2) change the password from 'iknowbesteffort' > 3) stop calling it 'experimental' in public > 4) tell people that if smth does not work they should fall back to the > 'standard' network and see if it helps. > I would be in agreement with the above too. I felt that it ?just worked? too and was very pleased to be using it. As a total newbie to RIPE meetings I thought it was a superb thing to have a v6 only SSID and I would endorse moving it forward to a standardised network with a buyer/user beware clause as such. I tried to test a variety of stuff whilst connected to the network and the likes of FaceTime to the family in Dublin worked flawlessly. Thanks again for a superb week! Hope to see you all again London. - Mick From gert at space.net Sat May 17 00:20:31 2014 From: gert at space.net (Gert Doering) Date: Sat, 17 May 2014 00:20:31 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: References: <6F0271D3-D319-4ED4-B973-62EA75B019C0@marcoh.net> Message-ID: <20140516222031.GA46558@Space.Net> Hi, On Fri, May 16, 2014 at 04:24:56PM +0200, Jen Linkova wrote: > What would be really awesome is to stop announcing that network as 'an > experiment'. My understanding is that we need > 1) [hardest part] get smth better than 'best effort' support level; > 2) change the password from 'iknowbesteffort' > 3) stop calling it 'experimental' in public > 4) tell people that if smth does not work they should fall back to the > 'standard' network and see if it helps. Seconded. This is what I disliked about the thing: the "oh, it's not going to work for you, it's just an experiment" touch the messages surrounding it had. > We could call it 'pilot', 'canary' or '1st phase of rollout' ;) "The future Internet" :) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From marcoh at marcoh.net Sat May 17 08:12:04 2014 From: marcoh at marcoh.net (MarcoH) Date: Sat, 17 May 2014 08:12:04 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: <20140516222031.GA46558@Space.Net> References: <6F0271D3-D319-4ED4-B973-62EA75B019C0@marcoh.net> <20140516222031.GA46558@Space.Net> Message-ID: Hi, Thanks for all your positive thoughts. Regarding bumping up the status, I already briefly spoke to Razvan. Once the RIPE68 dust has settled and everything is unpacked, we will organise a meeting to evaluate this instance and discuss the options to further progress this. To the call to provide a true IPv6 Only service, I am not a big fan. The goal when we started this was not to prove that without IPv4, the Internet as we know it does not exist. The idea is to show that there is a middle way in which you can build a network that still gives a good user experience but with far less stress on IPv4 resources. Also this provides a great testbed to see which applications or services rely on a working IPv4 stack or insist opening an IPv4 socket. I think we have to be realistic here and although everything can be build, to stick to the setup and the one (ok two) SSID we have. The setup is now pretty straightforward and does not require a lot of additional resources from the ops team or equipment. These peoples primary task is to run a meeting and provide a good experience for all attendees, doing network experiments is not their core business. At least not during the meeting itself. So any requests for additional features have to be carefully evaluated. Making sure they do not demand too much resources or risk damaging the overall experience of meeting attendees. Also keep in mind that RIPE is made up of a very broad group of people and not everybody has the technical knowledge to fix it themselves when things break. MarcoH -- Sent from mobile, sorry for the typos > On 17 mei 2014, at 00:20, Gert Doering wrote: > > Hi, > >> On Fri, May 16, 2014 at 04:24:56PM +0200, Jen Linkova wrote: >> What would be really awesome is to stop announcing that network as 'an >> experiment'. My understanding is that we need >> 1) [hardest part] get smth better than 'best effort' support level; >> 2) change the password from 'iknowbesteffort' >> 3) stop calling it 'experimental' in public >> 4) tell people that if smth does not work they should fall back to the >> 'standard' network and see if it helps. > > Seconded. This is what I disliked about the thing: the "oh, it's not > going to work for you, it's just an experiment" touch the messages > surrounding it had. > >> We could call it 'pilot', 'canary' or '1st phase of rollout' ;) > > "The future Internet" :) > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From bs at stepladder-it.com Sat May 17 11:05:05 2014 From: bs at stepladder-it.com (Benedikt Stockebrand) Date: Sat, 17 May 2014 09:05:05 +0000 Subject: [ipv6-wg] Follow-Up on Niall's talk: Ramond (RA Monitoring Daemon) In-Reply-To: <20140515155356.GD1054@ernw.de> (Enno Rey's message of "Thu, 15 May 2014 17:53:56 +0200") References: <877g5n3ylr.fsf@stepladder-it.com> <20140515155356.GD1054@ernw.de> Message-ID: <87zjig93ni.fsf@stepladder-it.com> Hi Enno and list, I'll skip my comments on the contexts where ramond is useful or not, as Tim has already pointed that out, but there are a couple more aspects in your posting I consider very important (and unsuitable for a quick reply from a conference auditorium): Enno Rey writes: > It would help against accidentally brought-in/fired-up systems > emitting rogue RAs (which, admittedly, in quite some networks > constitute a bigger risk than said attacker) That's the point: It is a tool for dealing with BYOD style ("guest" or whatever) networks where you have rather limited control over the devices being connected and your main concern are broken configurations on guest devices rather than malicious attackers. > but that threat/risk can easily be addressed with stuff like > "router-preference high" (or its equivalents) on the infrastructure > side. and this type of stuff/mitigation is available to _most_ > networks in the interim. That approach has the drawback that it doesn't let you prioritize your default routers. That's not an issue if you run a first hop redundancy protocol like VRRP/HSRP/CARP/..., but not everybody does that. Additionally, it doesn't provide two features I consider rather useful: If you hook up the ramond logging output to your monitoring, then you can keep an eye on the relevance of this issue in your particular networks. And if you actually use a proper response script so that offending devices are disabled, by shutting down the switch port in question or by locking the matching entry in your WiFi's Radius DB, you can actually make people contact your first level support/conference NOC/whatever so their misconfiguration can be fixed by people who know---which is of course For the Good of the Internet in General[TM]. > more importantly I'd like to ask you another question: how many > environments do you know which have a "mature network incident > response process" which would have to be followed once ramond "alerts > $ADMIN of $VIOLATION"? unfortunately there's usually a strong > correlation between "lack of appropriate tools" and "lack of process > maturity" so those environments where ramond could make sense will not > be able to make reasonable use of it anyway. There's a third aspect in here that you make assumptions about: What degree of authority does $ADMIN have to deal with $USER, or more specifically, with $DEVICE? If you run an 802.1x managed network with devices that you control through some sort of orchestration tool (puppet, cfengine, or whatever), that's a completely different situation than a $COFFEESHOP WiFi where people show up, turn on their own misconfigured devices, expect to get half an hour's worth of work done before they leave again, and your job is to keep them happy without. In a coffeeshop style environment you can define all the processes you like, but if the business case is not to step on any customer's toes (unless they intentionally did something seriously malicious and you can produce legal grade evidence and whatnot), your options are extremely limited. > In general, the "detection/reaction type of tools" (as opposed to a > "prevention-oriented" security approach) haven't proven their > usefullness too much in the past. If you have RA guard or similar available, by all means use it. But some people don't have that option. And beyond that, I think you still remember that I strongly promote to segment networks wherever feasible (and actually that's one of the reasons why I do that multicast routing presentation at the IPv6-Kongress in Frankfurt next week). But sometimes that's not an option either, and that's where the ramond becomes rather useful. Which brings us back to the beginning of the thread: I don't know Niall's setup itself, but from similar ones I've seen elsewhere, he might well run an environment where ramond is extremely useful. 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/ From Piotr.Strzyzewski at polsl.pl Sat May 17 11:19:55 2014 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Sat, 17 May 2014 11:19:55 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: References: <6F0271D3-D319-4ED4-B973-62EA75B019C0@marcoh.net> Message-ID: <20140517091955.GA26933@hydra.ck.polsl.pl> On Fri, May 16, 2014 at 09:15:02PM +0100, Mick O'Donovan wrote: > > What would be really awesome is to stop announcing that network as 'an > > experiment'. My understanding is that we need > > 1) [hardest part] get smth better than 'best effort' support level; > > 2) change the password from 'iknowbesteffort' > > 3) stop calling it 'experimental' in public > > 4) tell people that if smth does not work they should fall back to the > > 'standard' network and see if it helps. > > > > I would be in agreement with the above too. I felt that it ?just > worked? too and was very pleased to be using it. Although I have that feeling that we should move forwards, I don't find this network as "just worked". Together with my colleagues we fail to connect two android based phones. We have a little chat about that with Marco during one of the breaks. Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From gert at space.net Sat May 17 11:25:17 2014 From: gert at space.net (Gert Doering) Date: Sat, 17 May 2014 11:25:17 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: <20140517091955.GA26933@hydra.ck.polsl.pl> References: <6F0271D3-D319-4ED4-B973-62EA75B019C0@marcoh.net> <20140517091955.GA26933@hydra.ck.polsl.pl> Message-ID: <20140517092517.GB46558@Space.Net> Hi, On Sat, May 17, 2014 at 11:19:55AM +0200, Piotr Strzyzewski wrote: > Although I have that feeling that we should move forwards, I don't find > this network as "just worked". Together with my colleagues we fail to > connect two android based phones. We have a little chat about that with > Marco during one of the breaks. This is a known Android failure. If there is no IPv4, it will not connect to a WiFi network, unless you manually configure some (arbitrary) static IPv4 address on the interface. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From bs at stepladder-it.com Sat May 17 11:34:47 2014 From: bs at stepladder-it.com (Benedikt Stockebrand) Date: Sat, 17 May 2014 09:34:47 +0000 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: (Jen Linkova's message of "Fri, 16 May 2014 16:24:56 +0200") References: <6F0271D3-D319-4ED4-B973-62EA75B019C0@marcoh.net> Message-ID: <87sio892a0.fsf@stepladder-it.com> Hi Jen, Marco and list, I personally think that at event like the RIPE meeting we should actually be one of the first to do that due to the amount of experience and of people interested in the outcome around. We'll still need the vintage stuff around as a fallback (unless I finally get around to mod my ancient Galaxy Tab 10.1), but if the NOC crowd can actually handle this, what I'd like to see are three classes of networks/SSIDs/whatever: 0) IPv4 only (for disciplinary purposes:-) 1) IPv4+IPv6 dual stacked "vintage" network 2) IPv6+NAT64 "default" network 3) IPv6-only "see what already works" network Question is: With all the stress involved running a conference network, can the NOC handle that, and how can we help them if they are actually willing to try? Jen Linkova writes: > 2) change the password from 'iknowbesteffort' 2a) change the password for the vintage stuff to 'iknowiamtenyearsbehind':-) > 3) stop calling it 'experimental' in public 3a) and start calling the vintage stuff "dead and smelling":-) > I'm not suggesting making it a default network at the current stage > but I think that it is mature enough to move out of 'experimental' > phase. > We could call it 'pilot', 'canary' or '1st phase of rollout' ;) or "this is the last warning":-) SCNR OK, more seriously: Actually calling things by some name *is* important, so this is only half funny and half serious. 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/ From Piotr.Strzyzewski at polsl.pl Sat May 17 11:45:31 2014 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Sat, 17 May 2014 11:45:31 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: <20140517092517.GB46558@Space.Net> References: <6F0271D3-D319-4ED4-B973-62EA75B019C0@marcoh.net> <20140517091955.GA26933@hydra.ck.polsl.pl> <20140517092517.GB46558@Space.Net> Message-ID: <20140517094531.GB26933@hydra.ck.polsl.pl> On Sat, May 17, 2014 at 11:25:17AM +0200, Gert Doering wrote: Hi > On Sat, May 17, 2014 at 11:19:55AM +0200, Piotr Strzyzewski wrote: > > Although I have that feeling that we should move forwards, I don't find > > this network as "just worked". Together with my colleagues we fail to > > connect two android based phones. We have a little chat about that with > > Marco during one of the breaks. > > This is a known Android failure. If there is no IPv4, it will not > connect to a WiFi network, unless you manually configure some (arbitrary) > static IPv4 address on the interface. Heard the same thing from Marco. However, this means that some users will fail to use this network, due to the lack of experience/knowledge. :( Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From pch-ripeml at u-1.phicoh.com Sat May 17 11:46:23 2014 From: pch-ripeml at u-1.phicoh.com (Philip Homburg) Date: Sat, 17 May 2014 11:46:23 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: Your message of "Sat, 17 May 2014 08:12:04 +0200 ." Message-ID: In your letter dated Sat, 17 May 2014 08:12:04 +0200 you wrote: >The idea is to show that there is a middle way in which >you can build a network that still gives a good user experience but with far l >ess stress on IPv4 resources. I'm curious about this statement. Is NAT464 over wifi or wired ethernet really easier than IPv6 native plus NAT44? I know NAT464 has advantages for 3G networks, but I have not seen anymore doing a comparison for wifi. Does anyone have a pointer? From bs at stepladder-it.com Sat May 17 11:49:41 2014 From: bs at stepladder-it.com (Benedikt Stockebrand) Date: Sat, 17 May 2014 09:49:41 +0000 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: (marcoh@marcoh.net's message of "Sat, 17 May 2014 08:12:04 +0200") References: <6F0271D3-D319-4ED4-B973-62EA75B019C0@marcoh.net> <20140516222031.GA46558@Space.Net> Message-ID: <87iop491l6.fsf@stepladder-it.com> Hi Marco and list, MarcoH writes: > To the call to provide a true IPv6 Only service, I am not a big > fan. The goal when we started this was not to prove that without IPv4, > the Internet as we know it does not exist. The idea is to show that > there is a middle way in which you can build a network that still > gives a good user experience but with far less stress on IPv4 > resources. I wouldn't want this sort of setup so people actually use it to get things done, but to test what already works and what not while hanging out with other people who know about this. The IPv6-only SSID should really be experimental, and if it helps, we should take care of it ourselves rather than leave it to the NOC. > These peoples primary task is to run a meeting and provide a good > experience for all attendees, doing network experiments is not their > core business. At least not during the meeting itself. And it is also entirely their call what sort of resources and support they can give us without putting the conference network in general unnecessarily at risk. > So any requests for additional features have to be carefully > evaluated. Since you are the one in permanent contact with them: Please see what can be done without causing them any serious worries. The last thing I want to see is that the NOC crowd gets pissed off by things unnecessarily going wrong. We'll need them in the long run, too... 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/ From gert at space.net Sat May 17 12:01:46 2014 From: gert at space.net (Gert Doering) Date: Sat, 17 May 2014 12:01:46 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: <20140517094531.GB26933@hydra.ck.polsl.pl> References: <6F0271D3-D319-4ED4-B973-62EA75B019C0@marcoh.net> <20140517091955.GA26933@hydra.ck.polsl.pl> <20140517092517.GB46558@Space.Net> <20140517094531.GB26933@hydra.ck.polsl.pl> Message-ID: <20140517100146.GC46558@Space.Net> Hi, On Sat, May 17, 2014 at 11:45:31AM +0200, Piotr Strzyzewski wrote: > > This is a known Android failure. If there is no IPv4, it will not > > connect to a WiFi network, unless you manually configure some (arbitrary) > > static IPv4 address on the interface. > > Heard the same thing from Marco. However, this means that some users > will fail to use this network, due to the lack of experience/knowledge. > :( Yeah, which is why I'm not suggesting to have this as the *default* conference network. OTOH, maybe the Android camp will wake up one day, and will fix this... the bug is open long enough. http://code.google.com/p/android/issues/detail?id=32630 Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From bs at stepladder-it.com Sat May 17 12:11:21 2014 From: bs at stepladder-it.com (Benedikt Stockebrand) Date: Sat, 17 May 2014 10:11:21 +0000 Subject: [ipv6-wg] Follow-Up on Niall's talk: Ramond (RA Monitoring Daemon) In-Reply-To: <20140516153800.GH10353@ernw.de> (Enno Rey's message of "Fri, 16 May 2014 17:38:00 +0200") References: <877g5n3ylr.fsf@stepladder-it.com> <20140516153800.GH10353@ernw.de> Message-ID: <878uq090l2.fsf@stepladder-it.com> Hi Niall, Enno and list, I've just taken a bit of a look at these, and this is what I think: Enno Rey writes: > On Fri, May 16, 2014 at 03:18:14PM +0200, Niall O'Reilly wrote: >> >> The problem it addresses seems to be parallel to the one which has my >> main attention at the moment. I need to track NAs (including legitimate >> ones) rather than RAs. >> >> So far, I'm aware of the following two potential solutions whose trails >> seem worth following to find out more: >> >> https://nav.uninett.no/wiki/navfaq That seems to be quite the beast. It sounds interesting, but it may be way overkill if you only want to use it to monitor ND. >> https://6mon.iit.cnr.it/ On that page it says: ] 6MoN version 2.2 Released ] ] Improvements in RA analysis: ] ] Multiple IPv6 prefixes are now recognized ] ] Optional fields are handled properly Doesn't really make me feel that confident... > ipv6mon (http://www.si6networks.com/tools/ipv6mon/), > NDPmon (http://ndpmon.sourceforge.net/). > [...] > http://blog.webernetz.net/2014/03/17/monitoring-mac-ipv6-address-bindings/ >From what I've read, these seem to do the job Niall needs. However, the way they work it isn't perfectly reliable: They all work by attaching a listening device to the subnet, which is generally fine, but may be insufficient. An orthogonal approach might actually be to use information from the various routers in the network. These may not show who is doing things within the subnet only, but as soon as they send anything through a router, they can be tracked there. > Crossposting to IPv6hackers mailing list as guys over there might have > other/better suggestions. apologies in advance for this! No reason to apologize, it makes perfect sense. 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/ From tore at fud.no Sat May 17 12:17:18 2014 From: tore at fud.no (Tore Anderson) Date: Sat, 17 May 2014 12:17:18 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: <20140517094531.GB26933@hydra.ck.polsl.pl> References: <6F0271D3-D319-4ED4-B973-62EA75B019C0@marcoh.net> <20140517091955.GA26933@hydra.ck.polsl.pl> <20140517092517.GB46558@Space.Net> <20140517094531.GB26933@hydra.ck.polsl.pl> Message-ID: <5377372E.8020507@fud.no> * Piotr Strzyzewski > On Sat, May 17, 2014 at 11:25:17AM +0200, Gert Doering wrote: > >> This is a known Android failure. If there is no IPv4, it will not >> connect to a WiFi network, unless you manually configure some (arbitrary) >> static IPv4 address on the interface. > > Heard the same thing from Marco. However, this means that some users > will fail to use this network, due to the lack of experience/knowledge. True. However, keep in mind that this was true for the main ESSID "ripemtg" this year too: People with devices that didn't support 5GHz had to connect to the secondary ESSID. I think we could very well do the same with IPv4 as with 2.4GHz; take away backwards compatibility for both 2.4GHz and IPv4 on the main "ripemtg" ESSID, but keep a "ripemtg-legacy" or something like that available for devices that requires the presence of either 2.4GHz and/or IPv4. We wouldn't be the first conference to do so, either: https://fosdem.org/2014/news/2014-02-01-pushing-ipv6/ Tore From Piotr.Strzyzewski at polsl.pl Sat May 17 18:54:01 2014 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Sat, 17 May 2014 18:54:01 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: <5377372E.8020507@fud.no> References: <6F0271D3-D319-4ED4-B973-62EA75B019C0@marcoh.net> <20140517091955.GA26933@hydra.ck.polsl.pl> <20140517092517.GB46558@Space.Net> <20140517094531.GB26933@hydra.ck.polsl.pl> <5377372E.8020507@fud.no> Message-ID: <20140517165401.GA6116@hydra.ck.polsl.pl> On Sat, May 17, 2014 at 12:17:18PM +0200, Tore Anderson wrote: > * Piotr Strzyzewski > > > On Sat, May 17, 2014 at 11:25:17AM +0200, Gert Doering wrote: Hi > >> This is a known Android failure. If there is no IPv4, it will not > >> connect to a WiFi network, unless you manually configure some (arbitrary) > >> static IPv4 address on the interface. > > > > Heard the same thing from Marco. However, this means that some users > > will fail to use this network, due to the lack of experience/knowledge. > > True. However, keep in mind that this was true for the main ESSID > "ripemtg" this year too: People with devices that didn't support 5GHz > had to connect to the secondary ESSID. Good point. And if we assume that people have chosen 2.4GHz network mostly due to the lack of 5GHz support, then (according to the stats provided at the Friday plenary session) the number of such users is about twice as big as the number of Android users. Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From rogerj at gmail.com Sat May 17 19:35:16 2014 From: rogerj at gmail.com (=?UTF-8?Q?Roger_J=C3=B8rgensen?=) Date: Sat, 17 May 2014 19:35:16 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: References: <6F0271D3-D319-4ED4-B973-62EA75B019C0@marcoh.net> Message-ID: On Fri, May 16, 2014 at 4:24 PM, Jen Linkova wrote: > Thanks for organizing it, it just worked ;) > > What would be really awesome is to stop announcing that network as 'an > experiment'. My understanding is that we need > 1) [hardest part] get smth better than 'best effort' support level; > 2) change the password from 'iknowbesteffort' > 3) stop calling it 'experimental' in public > 4) tell people that if smth does not work they should fall back to the > 'standard' network and see if it helps. > > I'm not suggesting making it a default network at the current stage > but I think that it is mature enough to move out of 'experimental' > phase. > We could call it 'pilot', 'canary' or '1st phase of rollout' ;) I totally agree we should move forwards. I also agree with your points above, but then we have something called reality, an annoying thing that slow down progress... This time the reality is that as long as Android can't connect to a IPv6 only network without some manual hack it is a no-go there. It's' really sad, and incredible annoying because Google are so good in so many areas. In this case they really suck big time (sorry for the language). Is there a manager we can maybe name and shame to get it fixed within let's say 6months time? ..... However - on a more serious note. We might consider to stop calling it an experiment as a starter. Then we could see if it's possible for the RIPE tech staff to run it for the next meeting. The password could stay the same so it's clear to people that it's not an official network just yet, it's a pilot, pre-release or something. Then we could reevaluate how things worked out and what is missing before it can become a permanent thing... ? -- Roger Jorgensen | ROJO9-RIPE rogerj at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From jan at go6.si Sat May 17 19:37:05 2014 From: jan at go6.si (Jan Zorz @ go6.si) Date: Sat, 17 May 2014 19:37:05 +0200 Subject: [ipv6-wg] Vacancy - nominations can go here In-Reply-To: References: <82D2713E-9B05-4C95-85CF-918D94A4DA4C@marcoh.net> <5374B12D.9050502@go6.si> Message-ID: <53779E41.5090004@go6.si> On 15/05/14 15:45, Sander Steffann wrote: > Hi Jan, > >> To re-state what I said on the mike during the IPv6 WG meeting: >> ----- I'm already a BCOP TF co-chair and I have no idea how would >> co-chairing two groups work, but in case of *lack* of good >> candidates I suspect we might make it work somehow and I could also >> serve as a co-chair of IPv6 WG - but please consider other better >> candidates/volunteers first. ----- > > You already doing ISOC, Go6.si, RIPE PC, RIPE BCOP, working on > RIPE-554bis, working on the IPv6 document for helpdesks and probably > so many other wonderful things to promote IPv6. Make sure you can > handle the workload. We don't want to lose you because of burnout! > ;-) > > Cheers, and thank you for making so much your scarce time available > to this community! Sander Hey, You are probably right, but your (and other similar comments that I received during the week) makes me think that I did not clearly enough stated, that I'm volunteering as a backup, "gateway last resort" - in case nobody else (or too less people) volunteers. But now we've got 3 very good candidates - Jen, Dave and Benedikt - and I think we should rotate them in. Cheers, Jan From gert at space.net Sat May 17 19:38:13 2014 From: gert at space.net (Gert Doering) Date: Sat, 17 May 2014 19:38:13 +0200 Subject: [ipv6-wg] Vacancy - nominations can go here In-Reply-To: <53779E41.5090004@go6.si> References: <82D2713E-9B05-4C95-85CF-918D94A4DA4C@marcoh.net> <5374B12D.9050502@go6.si> <53779E41.5090004@go6.si> Message-ID: <20140517173813.GH46558@Space.Net> Hi, On Sat, May 17, 2014 at 07:37:05PM +0200, Jan Zorz @ go6.si wrote: > But now we've got 3 very good candidates - Jen, Dave and Benedikt - and > I think we should rotate them in. OTOH, this is the IPv*6* working group. 2 existing chairs, 4 new candidates, make a really nice number... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From marcoh at marcoh.net Sat May 17 19:43:45 2014 From: marcoh at marcoh.net (Marco Hogewoning) Date: Sat, 17 May 2014 19:43:45 +0200 Subject: [ipv6-wg] Vacancy - nominations can go here In-Reply-To: <20140517173813.GH46558@Space.Net> References: <82D2713E-9B05-4C95-85CF-918D94A4DA4C@marcoh.net> <5374B12D.9050502@go6.si> <53779E41.5090004@go6.si> <20140517173813.GH46558@Space.Net> Message-ID: > > OTOH, this is the IPv*6* working group. 2 existing chairs, 4 new candidates, > make a really nice number... 128 co-chairs? :) Grtx, MarcoH -- "Good tests kill flawed theories; we remain alive to guess again" From rogerj at gmail.com Sat May 17 19:53:13 2014 From: rogerj at gmail.com (=?UTF-8?Q?Roger_J=C3=B8rgensen?=) Date: Sat, 17 May 2014 19:53:13 +0200 Subject: [ipv6-wg] Vacancy - nominations can go here Message-ID: On Sat, May 17, 2014 at 7:37 PM, Jan Zorz @ go6.si wrote: > But now we've got 3 very good candidates - Jen, Dave and Benedikt - and I > think we should rotate them in. Excellent suggestion, let's rotate Jen, Dave and Benedikt in. -- Roger Jorgensen | ROJO9-RIPE rogerj at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From jan at go6.si Sat May 17 20:06:17 2014 From: jan at go6.si (Jan Zorz @ go6.si) Date: Sat, 17 May 2014 20:06:17 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: References: Message-ID: <5377A519.50603@go6.si> On 17/05/14 11:46, Philip Homburg wrote: > Is NAT464 over wifi or wired ethernet really easier than IPv6 native plus > NAT44? > > I know NAT464 has advantages for 3G networks, but I have not seen anymore > doing a comparison for wifi. Does anyone have a pointer? 2G/3G/4G and Wifi are two different things when we come to IPv6 provisioning. In 234G "mode" the pdpv6 context is established to SGSN and forwarded towards GGSN back in your home mobile network. When establishing pdpv6 context many things happen, "proprietary" IPv6 address provisioning (not DHCPv6 or RA or something similar) and also other parameters, including DNS resolver. Next thing that happens is that Android creates a CLAT virtual interface as soon as you establish pdp context, discovers the NAT64 prefix from your DNS64 server by asking for known A-only record and 464XLAT automagically starts to work and Skype does not complain anymore. With wifi things are different. There is still this bug that connection is marked non-working if there is no IPv4 address, but that's something that Google can probably fix pretty quickly. Next thing is that Android does not support DHCPv6 *at all* and probably never will. Maybe Erik or Lorenzo can explain it to you more thoroughly as I don't know what information has been published and what not ;) So next thing to look is RA included RDNS information that now growing number of OS-es and devices supports - and I need to check if this was already implemented in Android as there were rumors that suggested it. This brings us to a conclusion that 234G connection would work perfectly, but if you use wifi you get the IPv6 address, but no DNS and your connection will probably be marked as invalid. Cheers, Jan From pch-ripeml at u-1.phicoh.com Sat May 17 20:13:18 2014 From: pch-ripeml at u-1.phicoh.com (Philip Homburg) Date: Sat, 17 May 2014 20:13:18 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: Your message of "Sat, 17 May 2014 12:17:18 +0200 ." <5377372E.8020507@fud.no> Message-ID: In your letter dated Sat, 17 May 2014 12:17:18 +0200 you wrote: >True. However, keep in mind that this was true for the main ESSID >"ripemtg" this year too: People with devices that didn't support 5GHz >had to connect to the secondary ESSID. > >We wouldn't be the first conference to do so, either: >https://fosdem.org/2014/news/2014-02-01-pushing-ipv6/ Did a smiley get dropped? I know that IPv6 is boring enough that we need to come up with a new tunneling protocol every year to keep things interesting. But really? Af far as I can tell, the meeting network was perfect this year. When I opened my laptop, it just worked, both IPv4 and IPv6. So this proposal: - Introduces NAT when we now have real IPv4 connectivity. - The DNSSEC community is moving toward local validation. In the context of DNS64 this means no IPv4 connectivity for hosts that do local validation (can be fixed with NAT464) - Many people use third party DNS resolvers, like Google's. In the context of NAT64, this means no IPv4 connectivity (unless NAT464) - IPv4 literals also require NAT464. So the problems caused by NAT64 can be fixed by doing NAT464. Great. Then I need to ran NAT on my host and I get double NAT. Good luck trying to debug networking problems in that setup. So where we now have native IPv4 and dual stack that is supported by all devices (legacy devices that don't do IPv6 just work as before) the prosoal is to add a huge amount of protocol complexity, needlessly kill support for legacy devices. And complain about dual stack devices (like Android) that just don't support the tunneling protocol of the day. Maybe we can just leave it to the NCC ops to provide good IPv4 and IPv6 connectivity on the default network? From jan at go6.si Sat May 17 20:17:03 2014 From: jan at go6.si (Jan Zorz @ go6.si) Date: Sat, 17 May 2014 20:17:03 +0200 Subject: [ipv6-wg] Vacancy - nominations can go here In-Reply-To: <20140517173813.GH46558@Space.Net> References: <82D2713E-9B05-4C95-85CF-918D94A4DA4C@marcoh.net> <5374B12D.9050502@go6.si> <53779E41.5090004@go6.si> <20140517173813.GH46558@Space.Net> Message-ID: <5377A79F.7040500@go6.si> On 17/05/14 19:38, Gert Doering wrote: > Hi, > > On Sat, May 17, 2014 at 07:37:05PM +0200, Jan Zorz @ go6.si wrote: >> But now we've got 3 very good candidates - Jen, Dave and Benedikt - and >> I think we should rotate them in. > OTOH, this is the IPv*6* working group. 2 existing chairs, 4 new candidates, > make a really nice number... > Nice one :) cheers, Jan From michael.schneider at calispera.com Sat May 17 19:59:06 2014 From: michael.schneider at calispera.com (Michael Schneider/calispera.com) Date: Sat, 17 May 2014 19:59:06 +0200 Subject: [ipv6-wg] Vacancy - nominations can go here In-Reply-To: Message-ID: <4008B242-AD4A-433E-B0D5-9A567ED11725@calispera.com> Am 17.05.2014 um 19:53 schrieb "Roger J?rgensen" : On Sat, May 17, 2014 at 7:37 PM, Jan Zorz @ go6.si wrote: > But now we've got 3 very good candidates - Jen, Dave and Benedikt - and I > think we should rotate them in. Excellent suggestion, let's rotate Jen, Dave and Benedikt in. Privacy Extensions ;) Regards, Michael ________________________________ Michael Schneider,?Dipl.-Wirt.-Inf. CALISPERA.COM?InformationTechnology fon: +49(0)700.2254-7737 fax: -7730 http://www.calispera.com/de/kontakt Sorry to be brief - sent by mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Sat May 17 20:22:29 2014 From: gert at space.net (Gert Doering) Date: Sat, 17 May 2014 20:22:29 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: References: <5377372E.8020507@fud.no> Message-ID: <20140517182229.GI46558@Space.Net> Hi, On Sat, May 17, 2014 at 08:13:18PM +0200, Philip Homburg wrote: > In your letter dated Sat, 17 May 2014 12:17:18 +0200 you wrote: > >True. However, keep in mind that this was true for the main ESSID > >"ripemtg" this year too: People with devices that didn't support 5GHz > >had to connect to the secondary ESSID. > > > >We wouldn't be the first conference to do so, either: > >https://fosdem.org/2014/news/2014-02-01-pushing-ipv6/ > > Did a smiley get dropped? > > I know that IPv6 is boring enough that we need to come up with a new > tunneling protocol every year to keep things interesting. But really? The point is: while the RIPE meeting might be able to affort using a 1000 public IPv4 addresses on a conference network, not everyone will be able to do this in the future. So you'll see IPv6+NAT44 or IPv6+NAT64, and it's very good to make this crystal clear to application developers (= fosdem) and networking people (= ripe), so they can see if stuff needs fixing. [..] > So the problems caused by NAT64 can be fixed by doing NAT464. Great. > Then I need to ran NAT on my host and I get double NAT. Good luck trying > to debug networking problems in that setup. Why require IPv4 in the first place? Make sure the destination and the applications in question work over IPv6, done. > So where we now have native IPv4 and dual stack that is supported by all > devices (legacy devices that don't do IPv6 just work as before) the prosoal > is to add a huge amount of protocol complexity, needlessly kill support for > legacy devices. And complain about dual stack devices (like Android) that > just don't support the tunneling protocol of the day. A device that just plain fails to operate on an IPv6-only network has nothing to do with "tunneling protocol of the day". Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From pch-ripeml at u-1.phicoh.com Sat May 17 20:39:25 2014 From: pch-ripeml at u-1.phicoh.com (Philip Homburg) Date: Sat, 17 May 2014 20:39:25 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: Your message of "Sat, 17 May 2014 20:22:29 +0200 ." <20140517182229.GI46558@Space.Net> References: <5377372E.8020507@fud.no> <20140517182229.GI46558@Space.Net> Message-ID: In your letter dated Sat, 17 May 2014 20:22:29 +0200 you wrote: >The point is: while the RIPE meeting might be able to affort using a >1000 public IPv4 addresses on a conference network, not everyone will >be able to do this in the future. So you'll see IPv6+NAT44 or IPv6+NAT64, >and it's very good to make this crystal clear to application developers >(fosdem) and networking people (ripe), so they can see if stuff >needs fixing. So, we have one option, (IPv6+NAT44), no stuff needs fixing. We have another option, (IPv6+NAT64), stuff needs fixing. Maybe somebody needs to come up with a good justification for using NAT64 in the first place? (For networks other then ones with strange restrictions like 3G) Obviously, this is a very good argument for running NAT64 on an experimental network. >Why require IPv4 in the first place? Make sure the destination and the >applications in question work over IPv6, done. Yes. Let's make it such that the mail server that handles this list only accepts and delivers mail over IPv6. :-) Any of the current or prospective chairs willing to propose that? >> And complain about dual stack devices (like Android) that >> just don't support the tunneling protocol of the day. > >A device that just plain fails to operate on an IPv6-only network has >nothing to do with "tunneling protocol of the day". As far as I know, the only thing everybody cares about is IPv4 connectivity. That's why NAT464 was developed. Nobody seriously proposes to make an IPv6-only only network the default. At FOSDEM, usually the wifi in the big halls is completely overloaded. The best trick is then to go to the IPv6-only network, because nobody is using it. So, yes the IPv6-only option for Android would be really useful for FOSDEM. But not much else. From furry13 at gmail.com Sat May 17 21:07:36 2014 From: furry13 at gmail.com (Jen Linkova) Date: Sat, 17 May 2014 21:07:36 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: References: <6F0271D3-D319-4ED4-B973-62EA75B019C0@marcoh.net> <20140516222031.GA46558@Space.Net> Message-ID: Marco, On Sat, May 17, 2014 at 8:12 AM, MarcoH wrote: > Regarding bumping up the status, I already briefly spoke to Razvan. Once the RIPE68 dust has settled and everything is unpacked, we will organise a meeting to evaluate this instance and discuss the options to further progress this. Great! Let me know if I could help somehow (no, I *can not* fix Android bug, sorry ;((( - don't even ask...) > To the call to provide a true IPv6 Only service, I am not a big fan. The goal when we started this was not to prove that without IPv4, the Internet as we know it does not exist. The idea is to show that there is a middle way in which you can build a network that still gives a good user experience but with far less stress on IPv4 resources. > > Also this provides a great testbed to see which applications or services rely on a working IPv4 stack or insist opening an IPv4 socket. > > I think we have to be realistic here and although everything can be build, to stick to the setup and the one (ok two) SSID we have. The setup is now pretty straightforward and does not require a lot of additional resources from the ops team or equipment. These peoples primary task is to run a meeting and provide a good experience for all attendees, doing network experiments is not their core business. At least not during the meeting itself. > > So any requests for additional features have to be carefully evaluated. Making sure they do not demand too much resources or risk damaging the overall experience of meeting attendees. Also keep in mind that RIPE is made up of a very broad group of people and not everybody has the technical knowledge to fix it themselves when things break. Totally agree. I do hope that what I'm proposing is not going to put much load on ops people. I wonder if they got any complains coming to them about v6-only network last week? What was their experience? If ops team resources are the main concern, we need to think carefully about the support model/troubleshooting plan for v6-only SSID but it could be done. -- SY, Jen Linkova aka Furry From furry13 at gmail.com Sat May 17 21:18:15 2014 From: furry13 at gmail.com (Jen Linkova) Date: Sat, 17 May 2014 21:18:15 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: References: <6F0271D3-D319-4ED4-B973-62EA75B019C0@marcoh.net> Message-ID: On Sat, May 17, 2014 at 7:35 PM, Roger J?rgensen wrote: > On Fri, May 16, 2014 at 4:24 PM, Jen Linkova wrote: >> Thanks for organizing it, it just worked ;) >> >> What would be really awesome is to stop announcing that network as 'an >> experiment'. My understanding is that we need >> 1) [hardest part] get smth better than 'best effort' support level; >> 2) change the password from 'iknowbesteffort' >> 3) stop calling it 'experimental' in public >> 4) tell people that if smth does not work they should fall back to the >> 'standard' network and see if it helps. >> >> I'm not suggesting making it a default network at the current stage >> but I think that it is mature enough to move out of 'experimental' >> phase. >> We could call it 'pilot', 'canary' or '1st phase of rollout' ;) > > I totally agree we should move forwards. I also agree with your points > above, but then we have something called reality, an annoying thing > that slow down progress... > > This time the reality is that as long as Android can't connect to a > IPv6 only network without some manual hack it is a no-go there. I think I need to clarify: I'm *NOT* suggesting making v6-only network a default one, deprecate dual-stack SSID or anything like that. I propose just to change the way we are calling it and get official support. That's it. > However - on a more serious note. We might consider to stop calling it > an experiment as a starter. > Then we could see if it's possible for the RIPE tech staff to run it > for the next meeting. The password could stay the same so it's clear > to people that it's not an official network just yet, it's a pilot, > pre-release or something. OK, so you agree with all my suggestions except for changing the password? Well, I think we can reach a consensus then ;) > Then we could reevaluate how things worked out and what is missing > before it can become a permanent thing... ? Absolutely. -- SY, Jen Linkova aka Furry From elvis at velea.eu Sat May 17 21:34:35 2014 From: elvis at velea.eu (Elvis Velea) Date: Sat, 17 May 2014 21:34:35 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: References: <6F0271D3-D319-4ED4-B973-62EA75B019C0@marcoh.net> Message-ID: <5377B9CB.60107@velea.eu> Hi, I tried to test the experiment network on Friday as well. And kinda failed. On 17/05/14 21:18, Jen Linkova wrote: > On Sat, May 17, 2014 at 7:35 PM, Roger J?rgensen wrote: >> On Fri, May 16, 2014 at 4:24 PM, Jen Linkova wrote: >>> Thanks for organizing it, it just worked ;) >>> >>> What would be really awesome is to stop announcing that network as 'an >>> experiment'. My understanding is that we need >>> 1) [hardest part] get smth better than 'best effort' support level; >>> 2) change the password from 'iknowbesteffort' >>> 3) stop calling it 'experimental' in public >>> 4) tell people that if smth does not work they should fall back to the >>> 'standard' network and see if it helps. >>> >>> I'm not suggesting making it a default network at the current stage >>> but I think that it is mature enough to move out of 'experimental' >>> phase. >>> We could call it 'pilot', 'canary' or '1st phase of rollout' ;) >> I totally agree we should move forwards. I also agree with your points >> above, but then we have something called reality, an annoying thing >> that slow down progress... >> >> This time the reality is that as long as Android can't connect to a >> IPv6 only network without some manual hack it is a no-go there. > I think I need to clarify: I'm *NOT* suggesting making v6-only network > a default one, deprecate dual-stack SSID or anything like that. > I propose just to change the way we are calling it and get official > support. That's it. I think getting some support from the NCC OPS would be a great thing. Why I kinda failed to use the IPv6 only network was because there was something weird going on. I would connect to it, I would get an IPv6 address, the IPv6 address would then change (in a few seconds) to an other IPv6 address (as shown in the System Preferences -> Network on my Mac) and then the mac would say that I do not have a working connection. Second weird thing was that from time to time, over the same IPv6 only network I would get an IPv4 IP address from the conference network. The OPSie that was next to me when I was trying to troubleshoot this problem tried to contact MarcoH, but unfortunately MarcoH went offline a few minutes after the OPSie msg'ed him and we did not have the chance to really understand what was not working. > >> However - on a more serious note. We might consider to stop calling it >> an experiment as a starter. >> Then we could see if it's possible for the RIPE tech staff to run it >> for the next meeting. The password could stay the same so it's clear >> to people that it's not an official network just yet, it's a pilot, >> pre-release or something. > OK, so you agree with all my suggestions except for changing the password? Well, > I think we can reach a consensus then ;) > >> Then we could reevaluate how things worked out and what is missing >> before it can become a permanent thing... ? > Absolutely. > go for it, it will help people understand what breaks in their network. The only reason I was trying to test the IPv6 only network is to make sure that all our (V4Escrow) services are v6 capable. I even found out that the mail server was v6 capable but only over SMTP (and not IMAP) due to a configuration bug. Therefore, thumbs up for the effort, I managed to get something fixed ;) cheers, elvis From rogerj at gmail.com Sat May 17 21:43:09 2014 From: rogerj at gmail.com (=?UTF-8?Q?Roger_J=C3=B8rgensen?=) Date: Sat, 17 May 2014 21:43:09 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: References: <6F0271D3-D319-4ED4-B973-62EA75B019C0@marcoh.net> Message-ID: On Sat, May 17, 2014 at 9:18 PM, Jen Linkova wrote: > On Sat, May 17, 2014 at 7:35 PM, Roger J?rgensen wrote: >> This time the reality is that as long as Android can't connect to a >> IPv6 only network without some manual hack it is a no-go there. > > I think I need to clarify: I'm *NOT* suggesting making v6-only network > a default one, deprecate dual-stack SSID or anything like that. > I propose just to change the way we are calling it and get official > support. That's it. Guess my English failed me - as long as there are "bugs" like this Android one out there a IPv6 only network is a no-go. In that respect, I think the experiment so far has succeded. It has proven there is a showstopper for IPv6 only out there. Now we just need to wait for a fix:) >> However - on a more serious note. We might consider to stop calling it >> an experiment as a starter. >> Then we could see if it's possible for the RIPE tech staff to run it >> for the next meeting. The password could stay the same so it's clear >> to people that it's not an official network just yet, it's a pilot, >> pre-release or something. > > OK, so you agree with all my suggestions except for changing the password? Well, > I think we can reach a consensus then ;) > >> Then we could reevaluate how things worked out and what is missing >> before it can become a permanent thing... ? > > Absolutely. agree :-) ... another thing that hit me, what about seeing if the BCOP effort can help RIPE OPs to run the IPv6 only network? :) -- Roger Jorgensen | ROJO9-RIPE rogerj at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From furry13 at gmail.com Sat May 17 22:08:22 2014 From: furry13 at gmail.com (Jen Linkova) Date: Sat, 17 May 2014 22:08:22 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: <5377B9CB.60107@velea.eu> References: <6F0271D3-D319-4ED4-B973-62EA75B019C0@marcoh.net> <5377B9CB.60107@velea.eu> Message-ID: On Sat, May 17, 2014 at 9:34 PM, Elvis Velea wrote: > I tried to test the experiment network on Friday as well. And kinda failed. > Why I kinda failed to use the IPv6 only network was because there was > something weird going on. I would connect to it, I would get an IPv6 > address, the IPv6 address would then change (in a few seconds) to an other > IPv6 address (as shown in the System Preferences -> Network on my Mac) and > then the mac would say that I do not have a working connection. > > Second weird thing was that from time to time, over the same IPv6 only > network I would get an IPv4 IP address from the conference network. Very interesting..I did not see anything like that (I was using v6-only SSID all the time, no unpleasant surprises. A very few things did not work for me but it was expected and had nothing to do with RIPE network. > The OPSie that was next to me when I was trying to troubleshoot this problem > tried to contact MarcoH, but unfortunately MarcoH went offline a few minutes > after the OPSie msg'ed him and we did not have the chance to really > understand what was not working. OK, looks like we might need to think about support/escalation model for the next meeting ;) -- SY, Jen Linkova aka Furry From elvis at velea.eu Sat May 17 22:54:21 2014 From: elvis at velea.eu (Elvis Daniel Velea) Date: Sat, 17 May 2014 22:54:21 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: References: <6F0271D3-D319-4ED4-B973-62EA75B019C0@marcoh.net> <5377B9CB.60107@velea.eu> Message-ID: <-2215482844782217428@unknownmsgid> Hi, actually, my partly failed test was on Thursday in the afternoon. See more below, inline: Excuse the briefness of this mail, it was sent from a mobile device. > On 17 May 2014, at 22:08, Jen Linkova wrote: > >> On Sat, May 17, 2014 at 9:34 PM, Elvis Velea wrote: >> I tried to test the experiment network on Friday as well. And kinda failed. > >> Why I kinda failed to use the IPv6 only network was because there was >> something weird going on. I would connect to it, I would get an IPv6 >> address, the IPv6 address would then change (in a few seconds) to an other >> IPv6 address (as shown in the System Preferences -> Network on my Mac) and >> then the mac would say that I do not have a working connection. >> >> Second weird thing was that from time to time, over the same IPv6 only >> network I would get an IPv4 IP address from the conference network. > > Very interesting..I did not see anything like that (I was using > v6-only SSID all the time, > no unpleasant surprises. A very few things did not work for me but it > was expected and had nothing to do with RIPE network. That is what I was trying to test. To see if anything in my network or any of the services would fail. > >> The OPSie that was next to me when I was trying to troubleshoot this problem >> tried to contact MarcoH, but unfortunately MarcoH went offline a few minutes >> after the OPSie msg'ed him and we did not have the chance to really >> understand what was not working. > > OK, looks like we might need to think about support/escalation model > for the next meeting ;) Exactly what I ment to say. We can not expect to just request something and the RIPE NCC to provide. Support for an IPv6 only network will require more work for the NCC and probably a dedicated FTE because many attendees will come to ask all kind of questions and require help with troubleshooting all kind of weird problems. I would see the benefit - it will help attendees to fix broken IPv6 configurations and discover many bugs. I also see that the decission belongs to the NCC OPS Dept.. they already do a lot to support the meeting, remote access, etc.. cheers, elvis > > -- > SY, Jen Linkova aka Furry From gert at space.net Sat May 17 22:59:44 2014 From: gert at space.net (Gert Doering) Date: Sat, 17 May 2014 22:59:44 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: References: <5377372E.8020507@fud.no> <20140517182229.GI46558@Space.Net> Message-ID: <20140517205944.GA38510@Space.Net> Hi, On Sat, May 17, 2014 at 08:39:25PM +0200, Philip Homburg wrote: > So, we have one option, (IPv6+NAT44), no stuff needs fixing. We have another > option, (IPv6+NAT64), stuff needs fixing. You need more operational practice :-) - you *really* want to get rid of dual-stack wherever you can, and instead of having to maintain and monitor IPv4 *and* IPv6 throughout your network, IPv6+NAT64 gives you a nice and clean single-stack network, with an ugly IPv4 wart near the exit. Dual-Stack operation sucks big time, because it means you have to configure everything twice, monitor everything twice, firewall everything twice, etc. In some places, this is unavoidable (like, the internet facing edge of a service offering). In other places, we might eventually get rid of it, and "access networks" are exactly one of the places where it is possible, and saves big time. (Not that it would nicely work today, but unless you actually go and see what will break, it won't ever get fixed) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From pch-ripeml at u-1.phicoh.com Sat May 17 23:41:50 2014 From: pch-ripeml at u-1.phicoh.com (Philip Homburg) Date: Sat, 17 May 2014 23:41:50 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: Your message of "Sat, 17 May 2014 22:59:44 +0200 ." <20140517205944.GA38510@Space.Net> References: <5377372E.8020507@fud.no> <20140517182229.GI46558@Space.Net> <20140517205944.GA38510@Space.Net> Message-ID: In your letter dated Sat, 17 May 2014 22:59:44 +0200 you wrote: >You need more operational practice :-) - you *really* want to get rid of >dual-stack wherever you can, and instead of having to maintain and monitor >IPv4 *and* IPv6 throughout your network, IPv6+NAT64 gives you a nice and >clean single-stack network, with an ugly IPv4 wart near the exit. > >Dual-Stack operation sucks big time, because it means you have to configure >everything twice, monitor everything twice, firewall everything twice, etc. I'm curious how people want to transition to IPv6+NAT64. Of course, getting rid of IPv4 solves a lot of problems. But just any eyeball network will have to support IPv4 for a very long time. So we can bitch on this list about Android not supporting NAT464, but in reality, are you going to tell users to dump their old devices, just because they don't support NAT464? On the RIPE meeting network, if you have to support traditional dual stack in addition to NAT64, there is no net gain for the ops team. For any eyeball provider, how do you switch to NAT64? Can you tell all your customers to dump their old CPEs? Is upgrading all CPEs worth it? Does anybody know how to debug this stuff? And because you are effectively tunnelling IPv4, any ACL you would need in NAT44, you probably also need in NAT64. From marcoh at marcoh.net Sun May 18 10:00:23 2014 From: marcoh at marcoh.net (Marco Hogewoning) Date: Sun, 18 May 2014 10:00:23 +0200 Subject: [ipv6-wg] Vacancy - nominations can go here In-Reply-To: References: Message-ID: <1D614855-EEBA-4738-9100-1D27F7EBC8D3@marcoh.net> Please wait a bit :) a) there might be others b) as much as we don?t like overhead, let?s come up with some procedure c) I need to have a chat with Shane on exactly how we are going to do this I had several people including one of the candidates asking for a soft landing, where Shane and I gradually remove ourselves out of this, rather than just running off. So at a minimum we need to fix this in terms of timelines. Also it is not a given that there must be three, I think 4 is too many and you definitely need 2 for redundancy. First question to the group: how many working group chairs do you want in the end? Thanks, Marco On 17 mei 2014, at 19:53, Roger J?rgensen wrote: > On Sat, May 17, 2014 at 7:37 PM, Jan Zorz @ go6.si wrote: > >> But now we've got 3 very good candidates - Jen, Dave and Benedikt - and I >> think we should rotate them in. > > Excellent suggestion, let's rotate Jen, Dave and Benedikt in. > > > > -- > > Roger Jorgensen | ROJO9-RIPE > rogerj at gmail.com | - IPv6 is The Key! > http://www.jorgensen.no | roger at jorgensen.no > From marcoh at marcoh.net Sun May 18 10:04:55 2014 From: marcoh at marcoh.net (Marco Hogewoning) Date: Sun, 18 May 2014 10:04:55 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: <20140517182229.GI46558@Space.Net> References: <5377372E.8020507@fud.no> <20140517182229.GI46558@Space.Net> Message-ID: <5C43401F-2A4D-4A3E-9DC8-640968134996@marcoh.net> > > A device that just plain fails to operate on an IPv6-only network has > nothing to do with "tunneling protocol of the day". Let?s start by getting rid of those IPv4 dependencies, but make sure that when the device does connect?the whole Internet becomes reachable, wether it is on IPv6 or not. And what is left is deal with the protocol overhead of bad packet content that does not cater for translation or uses literals. And if your skype doesn?t work, there are others out there :) Grtx, MarcoH (no hats) From marcoh at marcoh.net Sun May 18 10:10:45 2014 From: marcoh at marcoh.net (Marco Hogewoning) Date: Sun, 18 May 2014 10:10:45 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: References: <6F0271D3-D319-4ED4-B973-62EA75B019C0@marcoh.net> <20140516222031.GA46558@Space.Net> Message-ID: <514FC68C-A3A7-40DA-8564-33E9CB2E912B@marcoh.net> > > Totally agree. I do hope that what I'm proposing is not going to put > much load on ops people. > I wonder if they got any complains coming to them about v6-only > network last week? What was their experience? > If ops team resources are the main concern, we need to think carefully > about the support model/troubleshooting plan for v6-only SSID but it > could be done. Stupid thought: would we be able to pull up enough volunteers to man/woman a support desk, similar to what ops does? At least for the London meeting. Simple task: spend a few hours (based on a pre-published schedule) at a designated spot so people can find you. Help them with troubleshooting, connecting and importantly document the issues. As such maybe we can create some sort of handover document, provide better statistical knowledge on workload and have some basic FAQ material which we can publish, also for others to use. DISCLAIMER: this idea just popped into my head, have no clue on what the RIPE NCC would think of such a setup Grtx, MarcoH -- "Good tests kill flawed theories; we remain alive to guess again" From tore at fud.no Sun May 18 10:37:47 2014 From: tore at fud.no (Tore Anderson) Date: Sun, 18 May 2014 10:37:47 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: References: Message-ID: <5378715B.2030906@fud.no> Hi Philip, > Did a smiley get dropped? No, I was being quite serious. Remember that are talking about the RIPE meeting here. The RIPE community and the NCC has for years now been encouraging the network operators in the region to adopt IPv6 because of IPv4 running out. In the last 20 months we have actually enforced this by refusing to give IPv4 addresses to network operators who actually need them. These operators have no choice in the matter, they will have to make do without the IPv4 they need no matter how difficult or painful that might be. The RIPE meeting network doesn't have that problem, of course. With a generously-sized IPv4 assignment, we are completely free to kick back, enjoy having IPv4 addresses for every device we bring, and consider IPv4 scarcity as ?Someone Else's Problem?. This would be having a double standard, though. I believe we should be eating our own dog food and ourselves do voluntarily what we are essentially forcing others to do. If we cannot start breaking our dependency on IPv4 at the RIPE meeting itself, how can we expect others to do so? Making the primary ESSID IPv6-only would be sending the right message, and demonstrate by example that what we are asking others to do, indeed can be done. (Hopefully! If we on the other hand are unable to do so, perhaps we need revise the entire ?deploy IPv6? message.) Undoubtedly, some people will experience difficulties using an IPv6-only network. Some issues we already know about, new ones might be revealed (and, with some luck, get fixed). However, as long as we provide a safety net in the form of an secondary IPv4-enabled ESSID, then I do not at all consider this to be a radical proposition. At least, no more radical than this year's decision to refuse 2.4GHz-only devices access to the main ESSID. Tore From tore at fud.no Sun May 18 10:48:38 2014 From: tore at fud.no (Tore Anderson) Date: Sun, 18 May 2014 10:48:38 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: <514FC68C-A3A7-40DA-8564-33E9CB2E912B@marcoh.net> References: <6F0271D3-D319-4ED4-B973-62EA75B019C0@marcoh.net> <20140516222031.GA46558@Space.Net> <514FC68C-A3A7-40DA-8564-33E9CB2E912B@marcoh.net> Message-ID: <537873E6.3070203@fud.no> * Marco Hogewoning > Stupid thought: would we be able to pull up enough volunteers to > man/woman a support desk, similar to what ops does? At least for the > London meeting. > > Simple task: spend a few hours (based on a pre-published schedule) at > a designated spot so people can find you. Help them with > troubleshooting, connecting and importantly document the issues. > > As such maybe we can create some sort of handover document, provide > better statistical knowledge on workload and have some basic FAQ > material which we can publish, also for others to use. If I go to London, I would happily volunteer for this. Tore From erey at ernw.de Sun May 18 10:44:48 2014 From: erey at ernw.de (Enno Rey) Date: Sun, 18 May 2014 10:44:48 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: <537873E6.3070203@fud.no> References: <6F0271D3-D319-4ED4-B973-62EA75B019C0@marcoh.net> <20140516222031.GA46558@Space.Net> <514FC68C-A3A7-40DA-8564-33E9CB2E912B@marcoh.net> <537873E6.3070203@fud.no> Message-ID: <20140518084448.GJ19821@ernw.de> Hi, On Sun, May 18, 2014 at 10:48:38AM +0200, Tore Anderson wrote: > * Marco Hogewoning > > > Stupid thought: would we be able to pull up enough volunteers to > > man/woman a support desk, similar to what ops does? At least for the > > London meeting. > > > > Simple task: spend a few hours (based on a pre-published schedule) at > > a designated spot so people can find you. Help them with > > troubleshooting, connecting and importantly document the issues. > > > > As such maybe we can create some sort of handover document, provide > > better statistical knowledge on workload and have some basic FAQ > > material which we can publish, also for others to use. > > If I go to London, I would happily volunteer for this. I will most probably to go London and would be available for that kind of support as well. Fully second it's a good idea to offer such support as well. best Enno > > Tore > -- 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 ======================================================= From zbynek at dialtelecom.cz Sun May 18 11:37:03 2014 From: zbynek at dialtelecom.cz (Zbynek Pospichal) Date: Sun, 18 May 2014 11:37:03 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: References: <6F0271D3-D319-4ED4-B973-62EA75B019C0@marcoh.net> <20140516222031.GA46558@Space.Net> Message-ID: <53787F3F.4050008@dialtelecom.cz> Dne 17.05.14 8:12, MarcoH napsal(a): Hi, > To the call to provide a true IPv6 Only service, I am not a big fan. The goal when we started this was not to prove that without IPv4, the Internet as we know it does not exist. The idea is to show that there is a middle way in which you can build a network that still gives a good user experience but with far less stress on IPv4 resources. The middle way is the current dual stack. I remember such test at RIPE meeting Berlin in 2008. It was the time to prove it is possible to use any 6->4 translation and live just with v6-only stack on a local network. Ok, we all know for a long time that it (almost) works and the situation is going better and better year by year. Now it's the time to speak about v6 on the whole Internet and here, sorry to say, but all the transition mechanisms except dual stack make the situation worse because such mechanisms limits the press from users to operators to implement native v6 on their access networks. I've seen a lot of stupid answers like "why do you need native v6? just use tunnels if you are insterested in" etc. >From my point of view, what is now necessary for wider v6 adoption is to show the people their existing v4-only services and provide them a motivation for an upgrade (which could be also, but, of course, not only, an inaccessibility of such services from networks declaring themselves as v6-only). BR, Zbynek From jan at go6.si Sun May 18 12:36:59 2014 From: jan at go6.si (Jan Zorz @ go6.si) Date: Sun, 18 May 2014 12:36:59 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: References: <5377372E.8020507@fud.no> <20140517182229.GI46558@Space.Net> <20140517205944.GA38510@Space.Net> Message-ID: <53788D4B.9060509@go6.si> On 17/05/14 23:41, Philip Homburg wrote: > So we can bitch on this list about Android not supporting NAT464, but in > reality, are you going to tell users to dump their old devices, just because > they don't support NAT464? I would suggest being precise in names here so everybody understands what we are talking about - its 464XLAT and not NAT464... http://tools.ietf.org/html/rfc6877 cheers, Jan From jan at go6.si Sun May 18 12:39:16 2014 From: jan at go6.si (Jan Zorz @ go6.si) Date: Sun, 18 May 2014 12:39:16 +0200 Subject: [ipv6-wg] Vacancy - nominations can go here In-Reply-To: <1D614855-EEBA-4738-9100-1D27F7EBC8D3@marcoh.net> References: <1D614855-EEBA-4738-9100-1D27F7EBC8D3@marcoh.net> Message-ID: <53788DD4.5080609@go6.si> On 18/05/14 10:00, Marco Hogewoning wrote: > First question to the group: how many working group chairs do you > want in the end? Seems like that 3 works fine as there is enough "resiliency" and also diversity :) cheers, Jan From jan at go6.si Sun May 18 12:43:14 2014 From: jan at go6.si (Jan Zorz @ go6.si) Date: Sun, 18 May 2014 12:43:14 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: <514FC68C-A3A7-40DA-8564-33E9CB2E912B@marcoh.net> References: <6F0271D3-D319-4ED4-B973-62EA75B019C0@marcoh.net> <20140516222031.GA46558@Space.Net> <514FC68C-A3A7-40DA-8564-33E9CB2E912B@marcoh.net> Message-ID: <53788EC2.4060501@go6.si> On 18/05/14 10:10, Marco Hogewoning wrote: > Stupid thought: would we be able to pull up enough volunteers to > man/woman a support desk, similar to what ops does? At least for the > London meeting. Not so stupid - actually brilliant! I volunteer to join this effort, specially because I would like to help people to make it work and also learn at the same time what their issues are as a very good input to our "IPv6 troubleshooting for helpdesks" document! > > Simple task: spend a few hours (based on a pre-published schedule) at > a designated spot so people can find you. Help them with > troubleshooting, connecting and importantly document the issues. Documenting the issues is really important. > > As such maybe we can create some sort of handover document, provide > better statistical knowledge on workload and have some basic FAQ > material which we can publish, also for others to use. maybe we could start a BCOP/IPv6-WG document "Running and troubleshooting IPv6-only wifi networks for events" That would be awesome... Cheers, Jan From furry13 at gmail.com Sun May 18 12:46:46 2014 From: furry13 at gmail.com (Jen Linkova) Date: Sun, 18 May 2014 12:46:46 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: <514FC68C-A3A7-40DA-8564-33E9CB2E912B@marcoh.net> References: <6F0271D3-D319-4ED4-B973-62EA75B019C0@marcoh.net> <20140516222031.GA46558@Space.Net> <514FC68C-A3A7-40DA-8564-33E9CB2E912B@marcoh.net> Message-ID: On Sun, May 18, 2014 at 10:10 AM, Marco Hogewoning wrote: > Stupid thought: would we be able to pull up enough volunteers to man/woman a support desk, similar to what ops does? At least for the London meeting. > > Simple task: spend a few hours (based on a pre-published schedule) at a designated spot so people can find you. Help them with troubleshooting, connecting and importantly document the issues. I think it doable - count me in. -- SY, Jen Linkova aka Furry From aledm at qix.co.uk Sun May 18 12:52:41 2014 From: aledm at qix.co.uk (Aled Morris) Date: Sun, 18 May 2014 11:52:41 +0100 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: <514FC68C-A3A7-40DA-8564-33E9CB2E912B@marcoh.net> References: <6F0271D3-D319-4ED4-B973-62EA75B019C0@marcoh.net> <20140516222031.GA46558@Space.Net> <514FC68C-A3A7-40DA-8564-33E9CB2E912B@marcoh.net> Message-ID: On 18 May 2014 09:10, Marco Hogewoning wrote: > > Stupid thought: would we be able to pull up enough volunteers to man/woman > a support desk, similar to what ops does? At least for the London meeting. > > Simple task: spend a few hours (based on a pre-published schedule) at a > designated spot so people can find you. Help them with troubleshooting, > connecting and importantly document the issues. I'd be happy to help with this. Aled -------------- next part -------------- An HTML attachment was scrubbed... URL: From furry13 at gmail.com Sun May 18 13:30:04 2014 From: furry13 at gmail.com (Jen Linkova) Date: Sun, 18 May 2014 13:30:04 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: <53788EC2.4060501@go6.si> References: <6F0271D3-D319-4ED4-B973-62EA75B019C0@marcoh.net> <20140516222031.GA46558@Space.Net> <514FC68C-A3A7-40DA-8564-33E9CB2E912B@marcoh.net> <53788EC2.4060501@go6.si> Message-ID: On Sun, May 18, 2014 at 12:43 PM, Jan Zorz @ go6.si wrote: >> As such maybe we can create some sort of handover document, provide >> better statistical knowledge on workload and have some basic FAQ >> material which we can publish, also for others to use. > > > maybe we could start a BCOP/IPv6-WG document "Running and troubleshooting > IPv6-only wifi networks for events" > > That would be awesome... I love this idea. I believe we should do it. It would make sense to reach out to NOC people of other conferences (IETF, Fosdem). Shall we discuss this BCOP initiative in bcop list (or in another thread)? -- SY, Jen Linkova aka Furry From erey at ernw.de Sun May 18 13:31:02 2014 From: erey at ernw.de (Enno Rey) Date: Sun, 18 May 2014 13:31:02 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: References: <6F0271D3-D319-4ED4-B973-62EA75B019C0@marcoh.net> <20140516222031.GA46558@Space.Net> <514FC68C-A3A7-40DA-8564-33E9CB2E912B@marcoh.net> <53788EC2.4060501@go6.si> Message-ID: <20140518113102.GB28026@ernw.de> Hi, On Sun, May 18, 2014 at 01:30:04PM +0200, Jen Linkova wrote: > On Sun, May 18, 2014 at 12:43 PM, Jan Zorz @ go6.si wrote: > >> As such maybe we can create some sort of handover document, provide > >> better statistical knowledge on workload and have some basic FAQ > >> material which we can publish, also for others to use. > > > > > > maybe we could start a BCOP/IPv6-WG document "Running and troubleshooting > > IPv6-only wifi networks for events" > > > > That would be awesome... > > I love this idea. I believe we should do it. It would make sense to > reach out to NOC people of other conferences (IETF, Fosdem). we run one recently at Troopers, see https://www.troopers.de/wp-content/uploads/2013/11/TROOPERS14-Case_Study-Building_a_Secure_IPv6_Guest_WiFi_Network-Christopher_Werny.pdf & are willing to contribute to both such a BCOP and as service desk guys in London... best Enno > Shall we discuss this BCOP initiative in bcop list (or in another thread)? > > -- > SY, Jen Linkova aka Furry > -- 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 ======================================================= From gert at space.net Sun May 18 13:38:49 2014 From: gert at space.net (Gert Doering) Date: Sun, 18 May 2014 13:38:49 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: References: <5377372E.8020507@fud.no> <20140517182229.GI46558@Space.Net> <20140517205944.GA38510@Space.Net> Message-ID: <20140518113849.GJ46558@Space.Net> Hi, On Sat, May 17, 2014 at 11:41:50PM +0200, Philip Homburg wrote: > For any eyeball provider, how do you switch to NAT64? Can you tell all your > customers to dump their old CPEs? Is upgrading all CPEs worth it? "Gradually". If you want a cable internet service here in .DE, what you will get today as a new customer is not "dual-stack" but IPv6+DS-Lite - which smells slightly more like "dual-stack" than IPv6+NAT64, but is far from "fully functional IPv4". Give it a few more years, and I'll bet you'll see IPv6+NAT64 deployments, just because it's easier and cheaper for the ISP to do. Client OSes are there, as soon as XP goes away. CPEs are what the ISPs will ship (= we have IPv6+DS-Lite today), and hopefully we can get the remaining applications fixed until then. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From gert at space.net Sun May 18 13:40:12 2014 From: gert at space.net (Gert Doering) Date: Sun, 18 May 2014 13:40:12 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: <537873E6.3070203@fud.no> References: <6F0271D3-D319-4ED4-B973-62EA75B019C0@marcoh.net> <20140516222031.GA46558@Space.Net> <514FC68C-A3A7-40DA-8564-33E9CB2E912B@marcoh.net> <537873E6.3070203@fud.no> Message-ID: <20140518114012.GK46558@Space.Net> Hi, On Sun, May 18, 2014 at 10:48:38AM +0200, Tore Anderson wrote: > > Simple task: spend a few hours (based on a pre-published schedule) at > > a designated spot so people can find you. Help them with > > troubleshooting, connecting and importantly document the issues. > > If I go to London, I would happily volunteer for this. +1. People seem find me anyway, even if not in a designated spot :-) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From swmike at swm.pp.se Sun May 18 13:46:29 2014 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 18 May 2014 13:46:29 +0200 (CEST) Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: <20140518113849.GJ46558@Space.Net> References: <5377372E.8020507@fud.no> <20140517182229.GI46558@Space.Net> <20140517205944.GA38510@Space.Net> <20140518113849.GJ46558@Space.Net> Message-ID: On Sun, 18 May 2014, Gert Doering wrote: > Client OSes are there, as soon as XP goes away. CPEs are what the ISPs > will ship (= we have IPv6+DS-Lite today), and hopefully we can get the > remaining applications fixed until then. NAT64 without 464XLAT doesn't give a good enough customer experience to "work". At least, this is my personal opinion after trying to get IPv6+NAT64 to work on a variety of client platforms. So my guess is that you're rather going to get MAP-T/MAP-E/ds.lite/lw4o6 kind of translation service in the CPE instead of relying on NAT64+DNS64. -- Mikael Abrahamsson email: swmike at swm.pp.se From gert at space.net Sun May 18 13:59:17 2014 From: gert at space.net (Gert Doering) Date: Sun, 18 May 2014 13:59:17 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: References: <5377372E.8020507@fud.no> <20140517182229.GI46558@Space.Net> <20140517205944.GA38510@Space.Net> <20140518113849.GJ46558@Space.Net> Message-ID: <20140518115917.GO46558@Space.Net> Hi, On Sun, May 18, 2014 at 01:46:29PM +0200, Mikael Abrahamsson wrote: > On Sun, 18 May 2014, Gert Doering wrote: > > > Client OSes are there, as soon as XP goes away. CPEs are what the ISPs > > will ship (= we have IPv6+DS-Lite today), and hopefully we can get the > > remaining applications fixed until then. > > NAT64 without 464XLAT doesn't give a good enough customer experience to > "work". At least, this is my personal opinion after trying to get > IPv6+NAT64 to work on a variety of client platforms. "Not yet". Which I think I implied, but maybe that should have been more obvious. Of course, as long as web designers are stupid enough to put IPv4 addresses in href= references of their web pages, and application developers are stupid enough to cling to "IPv4-only is good enough for us", you need some sort of dual-stack on the client stack - 464xlat, ds-lite, map, ... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From swmike at swm.pp.se Sun May 18 15:42:29 2014 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 18 May 2014 15:42:29 +0200 (CEST) Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: <20140518115917.GO46558@Space.Net> References: <5377372E.8020507@fud.no> <20140517182229.GI46558@Space.Net> <20140517205944.GA38510@Space.Net> <20140518113849.GJ46558@Space.Net> <20140518115917.GO46558@Space.Net> Message-ID: On Sun, 18 May 2014, Gert Doering wrote: > Of course, as long as web designers are stupid enough to put IPv4 > addresses in href= references of their web pages, and application > developers are stupid enough to cling to "IPv4-only is good enough for > us", you need some sort of dual-stack on the client stack - 464xlat, > ds-lite, map, ... Exactly, plus legacy applications that people still will be running in 5-10 years. -- Mikael Abrahamsson email: swmike at swm.pp.se From gert at space.net Sun May 18 18:50:07 2014 From: gert at space.net (Gert Doering) Date: Sun, 18 May 2014 18:50:07 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: References: <5377372E.8020507@fud.no> <20140517182229.GI46558@Space.Net> <20140517205944.GA38510@Space.Net> <20140518113849.GJ46558@Space.Net> <20140518115917.GO46558@Space.Net> Message-ID: <20140518165007.GP46558@Space.Net> Hi, On Sun, May 18, 2014 at 03:42:29PM +0200, Mikael Abrahamsson wrote: > On Sun, 18 May 2014, Gert Doering wrote: > > > Of course, as long as web designers are stupid enough to put IPv4 > > addresses in href= references of their web pages, and application > > developers are stupid enough to cling to "IPv4-only is good enough for > > us", you need some sort of dual-stack on the client stack - 464xlat, > > ds-lite, map, ... > > Exactly, plus legacy applications that people still will be running in > 5-10 years. A *home* user? The only "legacy application" a normal home user would know about is MSIE, and even that one does IPv6 these days. I'm not talking "enterprise" - those will have to cater their embedded machine control systems with only IPv4 support, based on WinXP embedded or the like, for the next 20+ years. And the legacy applications to talk to these... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From swmike at swm.pp.se Sun May 18 20:22:47 2014 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 18 May 2014 20:22:47 +0200 (CEST) Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: <20140518165007.GP46558@Space.Net> References: <5377372E.8020507@fud.no> <20140517182229.GI46558@Space.Net> <20140517205944.GA38510@Space.Net> <20140518113849.GJ46558@Space.Net> <20140518115917.GO46558@Space.Net> <20140518165007.GP46558@Space.Net> Message-ID: On Sun, 18 May 2014, Gert Doering wrote: > The only "legacy application" a normal home user would know about is > MSIE, and even that one does IPv6 these days. Let's take for instance MSN Messenger or Skype, those are not IPv6 enabled yet afaik. Then we can look at games that are run through online games, they usually have 5+ year lifetimes. A lot of people do more than web surfing and selling them a service that doesn't work with IPv4 only applications is asking for trouble. -- Mikael Abrahamsson email: swmike at swm.pp.se From tjc at ecs.soton.ac.uk Mon May 19 00:58:28 2014 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Sun, 18 May 2014 23:58:28 +0100 Subject: [ipv6-wg] Follow-Up on Niall's talk: Ramond (RA Monitoring Daemon) In-Reply-To: <878uq090l2.fsf@stepladder-it.com> References: <877g5n3ylr.fsf@stepladder-it.com> <20140516153800.GH10353@ernw.de> <878uq090l2.fsf@stepladder-it.com> <0CF0349D-AF9D-441E-AE1E-774339D6C018@ecs.soton.ac.uk> Message-ID: Hi, On 17 May 2014, at 11:11, Benedikt Stockebrand wrote: > Hi Niall, Enno and list, > > I've just taken a bit of a look at these, and this is what I think: > > Enno Rey writes: > >> On Fri, May 16, 2014 at 03:18:14PM +0200, Niall O'Reilly wrote: >>> >>> The problem it addresses seems to be parallel to the one which has my >>> main attention at the moment. I need to track NAs (including legitimate >>> ones) rather than RAs. >>> >>> So far, I'm aware of the following two potential solutions whose trails >>> seem worth following to find out more: >>> >>> https://nav.uninett.no/wiki/navfaq > > That seems to be quite the beast. It sounds interesting, but it may be > way overkill if you only want to use it to monitor ND. The point is that NAV does many very useful functions for an enterprise. It?s produced by the Norwegian NREN people, and actively supported, with version 4.0 just out. We?ve found it very good, at least with Cisco devices. The address tracking is one very useful feature of it. If you just want to track addresses, then it?s probably overkill. >>> https://6mon.iit.cnr.it/ > > On that page it says: > > ] 6MoN version 2.2 Released > ] > ] Improvements in RA analysis: > ] > ] Multiple IPv6 prefixes are now recognized > ] > ] Optional fields are handled properly > > Doesn't really make me feel that confident... > >> ipv6mon (http://www.si6networks.com/tools/ipv6mon/), >> NDPmon (http://ndpmon.sourceforge.net/). >> [...] >> http://blog.webernetz.net/2014/03/17/monitoring-mac-ipv6-address-bindings/ > >> From what I've read, these seem to do the job Niall needs. However, the > way they work it isn't perfectly reliable: They all work by attaching a > listening device to the subnet, which is generally fine, but may be > insufficient. > > An orthogonal approach might actually be to use information from the > various routers in the network. These may not show who is doing things > within the subnet only, but as soon as they send anything through a > router, they can be tracked there. > >> Crossposting to IPv6hackers mailing list as guys over there might have >> other/better suggestions. apologies in advance for this! > > No reason to apologize, it makes perfect sense. There have been some other interesting ND tracking tools posted here. I?m sure someone will remind us of them soon :) Tim > > > 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/ > From Timothy at tra.gov.om Mon May 19 05:51:53 2014 From: Timothy at tra.gov.om (Timothy Roy) Date: Mon, 19 May 2014 03:51:53 +0000 Subject: [ipv6-wg] IPV6 IPV4 work around Message-ID: <962B35EE7538DD448DF70940EE3756FA392992C1@TRASRV09.TRA.COM> Hi to All, I mentioned this a the Meeting in Warsaw but not sure if anyone really understood so I will submit it again. I realize that there will still be a lot of networks that will have to be able to translate over to IPV4 from IPV6 and vice versa. I also know that most are not too willing to obtain another piece of equipment for their system, but using a LTM (F5 LTM (which is what we will be using this year)) to do the translation from IPV6 to IPV4. This would be an excellent work around for quite a few issues that I have read about such as email. I have not tested this with email but will be testing it with our DNS very soon as I want to get our system on the IPV6 Internet so to speak. Just a thought and would also like to hear from anyone that may have already done so or tried to. Best Regards Tim Timothy Roy Regulatory and Compliance Unit Domain Name Operations Telecommunications Regulatory Authority. Tel: +968 24574858 Mobile: +968 93551117 Email: timothy at tra.gov.om Office hours: Sunday - Thursday, 7:30am - 3:00pm (Muscat GMT +4) -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.larsen at ip-only.se Mon May 19 10:54:52 2014 From: andreas.larsen at ip-only.se (Andreas Larsen) Date: Mon, 19 May 2014 08:54:52 +0000 Subject: [ipv6-wg] Vacancy - nominations can go here In-Reply-To: <53788DD4.5080609@go6.si> References: <1D614855-EEBA-4738-9100-1D27F7EBC8D3@marcoh.net> <53788DD4.5080609@go6.si> Message-ID: <8DF41387-DFFE-4FF4-BDD9-5D4B81AE734A@ip-only.se> I agree three is a good number like any good old raid setup. // Andreas Andreas Larsen IP-Only AB | Postadress: 753 81 UPPSALA | Bes?ksadress Uppsala: S:t Persg 6 Bes?ksadress Stockholm: N Stationsg 69 | Vxl: +46 18 843 10 00 | Mobil +46 70 843 10 56 www.ip-only.se 18 maj 2014 kl. 11:39 skrev Jan Zorz @ go6.si : > On 18/05/14 10:00, Marco Hogewoning wrote: >> First question to the group: how many working group chairs do you >> want in the end? > > Seems like that 3 works fine as there is enough "resiliency" and also diversity :) > > cheers, Jan > From training at ripe.net Mon May 19 10:59:21 2014 From: training at ripe.net (Training Services) Date: Mon, 19 May 2014 10:59:21 +0200 Subject: [ipv6-wg] [training] RIPE NCC Webinars - new dates Message-ID: <5379C7E9.2020204@ripe.net> 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 . We look forward to seeing you online. Kind regards, RIPE NCC Training Services From Piotr.Strzyzewski at polsl.pl Mon May 19 11:35:11 2014 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Mon, 19 May 2014 11:35:11 +0200 Subject: [ipv6-wg] Vacancy - nominations can go here In-Reply-To: <1D614855-EEBA-4738-9100-1D27F7EBC8D3@marcoh.net> References: <1D614855-EEBA-4738-9100-1D27F7EBC8D3@marcoh.net> Message-ID: <20140519093511.GB13430@hydra.ck.polsl.pl> On Sun, May 18, 2014 at 10:00:23AM +0200, Marco Hogewoning wrote: Dear Marco > First question to the group: how many working group chairs do you want in the end? Three. Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From jan at go6.si Mon May 19 12:01:28 2014 From: jan at go6.si (Jan Zorz @ go6.si) Date: Mon, 19 May 2014 12:01:28 +0200 Subject: [ipv6-wg] IPV6 IPV4 work around In-Reply-To: <962B35EE7538DD448DF70940EE3756FA392992C1@TRASRV09.TRA.COM> References: <962B35EE7538DD448DF70940EE3756FA392992C1@TRASRV09.TRA.COM> Message-ID: <5379D678.5090600@go6.si> On 19/05/14 05:51, Timothy Roy wrote: > I realize that there will still be a lot of networks that will have > to be able to translate over to IPV4 from IPV6 and vice versa. I also > know that most are not too willing to obtain another piece of > equipment for their system, but using a LTM (F5 LTM (which is what we > will be using this year)) to do the translation from IPV6 to IPV4. > This would be an excellent work around for quite a few issues that I > have read about such as email. I have not tested this with email but > will be testing it with our DNS very soon as I want to get our system > on the IPV6 Internet so to speak. Hi, there are several different ways how to do this, depending what you want to achieve. Let me point you to an excellent deployment oriented document written by Sander Steffan, that tells you how to enable your IPv4-only content or services on IPv6 network. http://www.internetsociety.org/deploy360/resources/making-content-available-over-ipv6/ I've been testing and running numerous mechanisms in this area in go6lab just to understand what works and what doesn't ;) Cheers, Jan From bs at stepladder-it.com Mon May 19 12:06:00 2014 From: bs at stepladder-it.com (Benedikt Stockebrand) Date: Mon, 19 May 2014 10:06:00 +0000 Subject: [ipv6-wg] Vacancy - nominations can go here In-Reply-To: <1D614855-EEBA-4738-9100-1D27F7EBC8D3@marcoh.net> (Marco Hogewoning's message of "Sun, 18 May 2014 10:00:23 +0200") References: <1D614855-EEBA-4738-9100-1D27F7EBC8D3@marcoh.net> Message-ID: <87d2faulpz.fsf@stepladder-it.com> Hi Marco and list, Marco Hogewoning writes: > Please wait a bit :) > a) there might be others Right. I suggest we wait at least for another week. (Anyone who thinks that this is too short speak up now.) > b) as much as we don?t like overhead, let?s come up with some procedure > c) I need to have a chat with Shane on exactly how we are going to do this I suggest this: We wait until Monday next week and see if anybody else volunteers. If there are, then I'd personally like a discussion among us volunteers about what team would make most sense. If we don't reach a result that way, we might have to come up with some sort of voting or such. Otherwise, I guess we're pretty much settled anyway. > I had several people including one of the candidates asking for a soft > landing, where Shane and I gradually remove ourselves out of this, > rather than just running off. So at a minimum we need to fix this in > terms of timelines. >From somewhat similar personal experiences in the past, this is absolutely essential. How about this: Once we've come up with the new team, we add the new team to the ipv6-wg-chair mailing list in an "advisory" role and eventually swap "active chair" and "advisory" roles between the old and new crowd. We can sort out the timing and sequence of swaps later on. > Also it is not a given that there must be three, I think 4 is too many > and you definitely need 2 for redundancy. > First question to the group: how many working group chairs do you want > in the end? I agree that four is too many; more often than not that leads to everyone expecting everyone else to either do things or take the blame for some screw-up, plus the extra hassle of getting ourselves coordinated (even real world scheduling problems are NP-hard...). But I'd rather not go with a team of two: We all have our daytime jobs, and as such there will be times when some of us are simply unavailable for several days. With only two of us I think this is just asking for trouble. And this isn't only about redundancy, but also about covering IPv6 from different perspectives. Dave has an ISP background, Jen sort of represents the contents side and as far as I am concerned, I am mostly all over the place but with some extra understanding for the eyeball and small/medium business side, among other things. That looks like a well-balanced team to me. And finally, from what I've seen of Jen and Dave so far, as far as I am concerned I think I can get along with them nicely to actually work as a team. 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/ From bs at stepladder-it.com Mon May 19 12:52:29 2014 From: bs at stepladder-it.com (Benedikt Stockebrand) Date: Mon, 19 May 2014 10:52:29 +0000 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: <514FC68C-A3A7-40DA-8564-33E9CB2E912B@marcoh.net> (Marco Hogewoning's message of "Sun, 18 May 2014 10:10:45 +0200") References: <6F0271D3-D319-4ED4-B973-62EA75B019C0@marcoh.net> <20140516222031.GA46558@Space.Net> <514FC68C-A3A7-40DA-8564-33E9CB2E912B@marcoh.net> Message-ID: <874n0mujki.fsf@stepladder-it.com> Hi Marco and list, Marco Hogewoning writes: > Stupid thought: would we be able to pull up enough volunteers to > man/woman a support desk, similar to what ops does? At least for the > London meeting. > [...] good idea, but to get this going I think the first step is to bring Razvan's team into the discussion. Anything to do with operations is their call anyway, and making plans that they eventually decide are impractical is a waste of time. Just to be sure, I've just sent them (opsmtg at ripe.net) a short mail pointing them to this discussion. 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/ From bs at stepladder-it.com Mon May 19 12:55:33 2014 From: bs at stepladder-it.com (Benedikt Stockebrand) Date: Mon, 19 May 2014 10:55:33 +0000 Subject: [ipv6-wg] Follow-Up on Niall's talk: Ramond (RA Monitoring Daemon) In-Reply-To: (Tim Chown's message of "Sun, 18 May 2014 23:58:28 +0100") References: <877g5n3ylr.fsf@stepladder-it.com> <20140516153800.GH10353@ernw.de> <878uq090l2.fsf@stepladder-it.com> <0CF0349D-AF9D-441E-AE1E-774339D6C018@ecs.soton.ac.uk> Message-ID: <87zjiet4uy.fsf@stepladder-it.com> Hi Tim and list, Tim Chown writes: >> That seems to be quite the beast. It sounds interesting, but it may be >> way overkill if you only want to use it to monitor ND. > > The point is that NAV does many very useful functions for an > enterprise. [...] that's what I meant. It has a whole pile of interesting features, but if all you want is ND monitoring *only*, then it may be overkill. 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/ From marcoh at marcoh.net Mon May 19 13:06:15 2014 From: marcoh at marcoh.net (Marco Hogewoning) Date: Mon, 19 May 2014 13:06:15 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: <874n0mujki.fsf@stepladder-it.com> References: <6F0271D3-D319-4ED4-B973-62EA75B019C0@marcoh.net> <20140516222031.GA46558@Space.Net> <514FC68C-A3A7-40DA-8564-33E9CB2E912B@marcoh.net> <874n0mujki.fsf@stepladder-it.com> Message-ID: <71B11DF3-C8FB-4A21-AD4D-5690921ED641@marcoh.net> > good idea, but to get this going I think the first step is to bring > Razvan's team into the discussion. Anything to do with operations is > their call anyway, and making plans that they eventually decide are > impractical is a waste of time. > > Just to be sure, I've just sent them (opsmtg at ripe.net) a short mail > pointing them to this discussion. Thanks for your help, as I indicated earlier I am already working with Razvan and we already decided that we have a meeting about this as soon as everybody is back on his feet. Marco From bs at stepladder-it.com Mon May 19 13:17:35 2014 From: bs at stepladder-it.com (Benedikt Stockebrand) Date: Mon, 19 May 2014 11:17:35 +0000 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: <71B11DF3-C8FB-4A21-AD4D-5690921ED641@marcoh.net> (Marco Hogewoning's message of "Mon, 19 May 2014 13:06:15 +0200") References: <6F0271D3-D319-4ED4-B973-62EA75B019C0@marcoh.net> <20140516222031.GA46558@Space.Net> <514FC68C-A3A7-40DA-8564-33E9CB2E912B@marcoh.net> <874n0mujki.fsf@stepladder-it.com> <71B11DF3-C8FB-4A21-AD4D-5690921ED641@marcoh.net> Message-ID: <87sio6t3u8.fsf@stepladder-it.com> Hi Marco and list, Marco Hogewoning writes: > Thanks for your help, as I indicated earlier I am already working with > Razvan ouch, I've somehow missed that. Looks like I still need to catch up with sleep, too:-( > and we already decided that we have a meeting about this as soon as > everybody is back on his feet. Good. Maybe we should give them some time to think it over before we make any more plans here? 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/ From edoardo.martelli at cern.ch Mon May 19 14:38:35 2014 From: edoardo.martelli at cern.ch (Edoardo Martelli) Date: Mon, 19 May 2014 14:38:35 +0200 Subject: [ipv6-wg] Vacancy - nominations can go here In-Reply-To: <1D614855-EEBA-4738-9100-1D27F7EBC8D3@marcoh.net> References: <1D614855-EEBA-4738-9100-1D27F7EBC8D3@marcoh.net> Message-ID: <5379FB4B.5030309@cern.ch> Hi > a) there might be others Thanks. I thought of volunteering as well, but it took me some time to get the support of my management. Quickly there was a good team of candidates, and I decided to drop the matter. Thanks to your email, but still with a feeling of uncertainty, I'm now sending my application. About myself: I may not be well know to the RIPE community, but I've attended RIPE meetings regularly once per year since RIPE39. I worked for an Italian then European ISP for several years, until the burst of the bubble pushed me to CERN; I've been working in the Network Engineering team since. I've supervised the IPv6 deployment at CERN that I presented last week; I'm involved in the working group that is pushing IPv6 adoption in the High Energy Physics community. My organisation was one of the founder of RIPE and hosted several of the first meetings. It's an LIR, serving few international organizations in the Geneva area. It hosts a RIS server (04), an Atlas Anchor and few probes, a K-root instance. > First question to the group: how many working group chairs do you want in the end? I agree three people can make an effective and resilient team Edoardo From em.mlist at gmail.com Mon May 19 14:41:59 2014 From: em.mlist at gmail.com (Edoardo Martelli) Date: Mon, 19 May 2014 14:41:59 +0200 Subject: [ipv6-wg] Vacancy - nominations can go here In-Reply-To: <1D614855-EEBA-4738-9100-1D27F7EBC8D3@marcoh.net> References: <1D614855-EEBA-4738-9100-1D27F7EBC8D3@marcoh.net> Message-ID: <5379FC17.4070707@gmail.com> Hi > a) there might be others Thanks. I thought of volunteering as well, but it took me some time to get the support of my management. Quickly there was a good team of candidates, and I decided to drop the matter. Thanks to your email, but still with a feeling of uncertainty, I'm now sending my application. About myself: I may not be well know to the RIPE community, but I've attended RIPE meetings regularly once per year since RIPE39. I worked for an Italian then European ISP for several years, until the burst of the bubble pushed me to CERN; I've been working in the Network Engineering team since. I've supervised the IPv6 deployment at CERN that I presented last week; I'm involved in the working group that is pushing IPv6 adoption in the High Energy Physics community. My organisation was one of the founder of RIPE and hosted several of the first meetings. It's an LIR, serving few international organizations in the Geneva area. It hosts a RIS server (04), an Atlas Anchor and few probes, a K-root instance. > First question to the group: how many working group chairs do you want in the end? I agree three people can make an effective and resilient team Edoardo From furry13 at gmail.com Mon May 19 17:25:05 2014 From: furry13 at gmail.com (Jen Linkova) Date: Mon, 19 May 2014 17:25:05 +0200 Subject: [ipv6-wg] Vacancy - nominations can go here In-Reply-To: <87d2faulpz.fsf@stepladder-it.com> References: <1D614855-EEBA-4738-9100-1D27F7EBC8D3@marcoh.net> <87d2faulpz.fsf@stepladder-it.com> Message-ID: On Mon, May 19, 2014 at 12:06 PM, Benedikt Stockebrand wrote: >> Please wait a bit :) >> a) there might be others > > Right. I suggest we wait at least for another week. (Anyone who thinks > that this is too short speak up now.) I'd suggest to wait a bit longer to give a chance to people who are on vacation currently. What about waiting till, let's say, EOB Fri June 6th (nice date, btw) so it will be 3+ weeks since the initial announcement. >> First question to the group: how many working group chairs do you want >> in the end? I agree that 3 is a good number: still easy to coordinate, redundant enough. > But I'd rather not go with a team of two: We all have our daytime jobs, > and as such there will be times when some of us are simply unavailable > for several days. With only two of us I think this is just asking for > trouble. +1. -- SY, Jen Linkova aka Furry From marcoh at marcoh.net Mon May 19 18:55:27 2014 From: marcoh at marcoh.net (Marco Hogewoning) Date: Mon, 19 May 2014 18:55:27 +0200 Subject: [ipv6-wg] Vacancy - nominations can go here In-Reply-To: References: <1D614855-EEBA-4738-9100-1D27F7EBC8D3@marcoh.net> <87d2faulpz.fsf@stepladder-it.com> Message-ID: <139C2A2A-E1C5-450F-B949-8C1B88F2FC56@marcoh.net> > I'd suggest to wait a bit longer to give a chance to people who are on > vacation currently. > What about waiting till, let's say, EOB Fri June 6th (nice date, btw) > so it will be 3+ weeks since the initial announcement. Seems like a reasonable plan, as far as the rest of the decision making process goes?might be worth to give Shane and me some time to fix a proper proposal, which will be sent to the list. Until then, nothing can be considered final :) Grtx, MarcoH -- "Good tests kill flawed theories; we remain alive to guess again" From pch-ripeml at u-1.phicoh.com Mon May 19 20:00:10 2014 From: pch-ripeml at u-1.phicoh.com (Philip Homburg) Date: Mon, 19 May 2014 20:00:10 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: Your message of "Sun, 18 May 2014 10:37:47 +0200 ." <5378715B.2030906@fud.no> References: <5378715B.2030906@fud.no> Message-ID: In your letter dated Sun, 18 May 2014 10:37:47 +0200 you wrote: >This would be having a double standard, though. I believe we should be eating our own dog food and ourselves do voluntarily what we are >essentially forcing others to do. If we cannot start breaking our >dependency on IPv4 at the RIPE meeting itself, how can we expect others >to do so? Making the primary ESSID IPv6-only would be sending the right >message, and demonstrate by example that what we are asking others to >do, indeed can be done. (Hopefully! If we on the other hand are unable >to do so, perhaps we need revise the entire ?deploy IPv6? message.) Note, I'm talking about the proposal to make the detault meeting network support 464XLAT. I don't think there is any proposal to make the default meeting network IPv6-only (i.e. without any support for IPv4) In this context, I don't think 464XLAT is eating our own dog food. It is for the small group that defined the 464XLAT specs, wrote the implementations, and are responsible for operating system integration. But for the rest of us, just about all people at the meeting, 464XLAT provides access to IPv4 like any other NAT implementation. Anyone who is still firmly stuck in supporting just the legacy protocol will have no problems with such a network. It does not encourage any of the RIPE members to do anything. Worse, suppose someone has spend a lot of time making sure that his network supports IPv6 in every possible way, shows up at a RIPE meeting with an Android phone and finds that he doesn't have network access. Not because of some IPv6 issue. No, because the network is deliberately set up in a way that is incompatible with Android. Not good. Now it would be eating our own dog food if there were a RIPE BCP publication that states that the best way to provide IPv4 on a modern wifi is NAT64. However, as far as I know, there is no such document, no plans for it, and I would be surprised major wifi hotspot would want to move to 464XLAT. But you never know. Until then, 464XLAT is just one of the many ways of providing IPv4 next to IPv6. With some advantages, but also many disadvantages. From tore at fud.no Tue May 20 02:06:13 2014 From: tore at fud.no (Tore Anderson) Date: Tue, 20 May 2014 02:06:13 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: References: <5378715B.2030906@fud.no> Message-ID: <537A9C75.7060603@fud.no> * Philip Homburg > Note, I'm talking about the proposal to make the detault meeting > network support 464XLAT. I don't think there is any proposal to make > the default meeting network IPv6-only (i.e. without any support for > IPv4) I don't think you can say that "the network support supports 464XLAT" as 464XLAT consists of two components, of which only one (the PLAT, or in other words the NAT64 gateway) is implemented in the network. The other component, the CLAT, is located on the end-user device itself. If the end-user device doesn't have a CLAT implementation, it will be able to access the IPv4 internet using DNS64/NAT64. So, for the record, this is the network type I would like to see be the default; IPv6-only on the LAN itself, but with DNS64 and NAT64 service somewhere in the upstream network. And yes, I am fully aware that this would preclude all current Android devices from connecting to it without configuring some manual network settings. > But for the rest of us, just about all people at the meeting, > 464XLAT provides access to IPv4 like any other NAT implementation. > Anyone who is still firmly stuck in supporting just the legacy > protocol will have no problems with such a network. It does not > encourage any of the RIPE members to do anything. You never know. The RIPE meeting is regularly attended by folks who are working for the vendors and are actually in a position to do something about various bugs. We also have a opensource wg and lots of skilled techies which could potentially find the extra motivation they need to actually go and fix bugs or shortcomings in open-source projects. It's far from a certainty, of course, but if I've learned one thing from when I was repeatedly pestering vendors to fix various ?IPv6 brokenness? issues it's that it actually has an effect to highlight an issue over and over again if you want to see it fixed. > Worse, suppose someone has spend a lot of time making sure that his > network supports IPv6 in every possible way, shows up at a RIPE > meeting with an Android phone and finds that he doesn't have network > access. Not because of some IPv6 issue. No, because the network is > deliberately set up in a way that is incompatible with Android. Not > good. If you look at R?zvan's slides at https://ripe68.ripe.net/presentations/505-RIPE_68_Technical_Report.pdf, you'll see that 33% of all clients were using the fallback "ripemtg-2.4" network. Presumably they did so out of necessity - at least I can think of no good explanation why anyone would deliberately choose a non-default 2.4GHz network if they had the option of choosing the default interference-free 5GHz network instead. So at RIPE68, the network was apparently deliberately set up in a way that was incompatible with one-third of the clients. Not good? Well, from what I can tell, this appears to have been completely uncontroversial! If I again look at R?zvan's slides, I see that Android was only 16% of all the clients. So what I struggle to understand is why it would be so terrible to set up the network in a way that is incompatible with 16% of the clients, while at the same time setting it up in a way that is incompatible with 33% of the clients is totally fine? Clearly, the viability of both approaches would depend entirely on the availability of a fallback network where the incompatible clients could connect instead. That was in place at RIPE68, and I'm certainly not proposing to take that away. > Now it would be eating our own dog food if there were a RIPE BCP > publication that states that the best way to provide IPv4 on a modern > wifi is NAT64. However, as far as I know, there is no such document, > no plans for it, and I would be surprised major wifi hotspot would > want to move to 464XLAT. But you never know. We are talking about the RIPE meeting here, not a random wifi hotspot at your local coffee shop or wherever. We're the ones actually insisting that others to go do this IPv6 thing, so we should really be at the forefront of such efforts ourselves. If the BCP you're describing is to ever be written, we can't expect that a coffee shop, airport or whatever will provide the deployment experience on which such a document could be based - the RIPE meeting, on the other hand, would be a perfect fit. Tore From marco.sommani at cnr.it Tue May 20 09:00:33 2014 From: marco.sommani at cnr.it (Marco Sommani) Date: Tue, 20 May 2014 09:00:33 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: <537A9C75.7060603@fud.no> References: <5378715B.2030906@fud.no> <537A9C75.7060603@fud.no> Message-ID: <8C166CDC-BFB0-49AC-8BFD-DB12C4F99AAD@cnr.it> On 20/mag/2014, at 02:06, Tore Anderson wrote: > * Philip Homburg > >> Note, I'm talking about the proposal to make the detault meeting >> network support 464XLAT. I don't think there is any proposal to make >> the default meeting network IPv6-only (i.e. without any support for >> IPv4) > > I don't think you can say that "the network support supports 464XLAT" > as 464XLAT consists of two components, of which only one (the PLAT, or > in other words the NAT64 gateway) is implemented in the network. The > other component, the CLAT, is located on the end-user device itself. Not necessarily. This picture, taken from rfc6877, shows the general 464XLAT scenario: +------+ | v6 | | host | +--+---+ | .---+---. / \ / IPv6 \ | Internet | \ / `----+----' | +------+ | .---+---. .------. | v6 +---+ +------+ / \ +------+ / \ | host | | | | / IPv6 \ | | / IPv4 \ +------+ +---+ CLAT +---+ Network +---+ PLAT +---+ Internet | +--------+ | | | \ / | | \ / | v4p/v6 +-+ +------+ `---------' +------+ `----+----' | host | | | +--------+ | +--+---+ +------+ | | v4g | | v4p +---+ | host | | host | | +------+ +------+ | <- v4p -> XLAT <--------- v6 --------> XLAT <- v4g -> v6 : Global IPv6 v4p : Private IPv4 v4g : Global IPv4 Figure 1: Wireline Network Topology The CLAT must not necessarily stay on end-user devices, because it may also be in a box at the border of a dual-stack customer network. On the other hand, I have to agree that this setup is useless for the purpose of offering to participants the experience of an IPv6-only world (actually, they would continue to experience dual-stack). On the other hand, this setup could be useful to convince the operators that, even if they eliminate IPv4 from their backbones, their customers may still continue to have IPv4 as usual. -- Marco Sommani Via Contessa Matilde 64C 56123 Pisa - Italia phone: +390500986728 mobile: +393487981019 fax: +390503869728 email: marcosommani at gmail.com -- Marco Sommani Consiglio Nazionale delle Ricerche Istituto di Informatica e Telematica Via Giuseppe Moruzzi 1 56124 Pisa - Italia work: +390506212127 mobile: +393487981019 fax: +390503158327 mailto:marco.sommani at cnr.it From jan at go6.si Tue May 20 09:47:36 2014 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 20 May 2014 09:47:36 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: <537A9C75.7060603@fud.no> References: <5378715B.2030906@fud.no> <537A9C75.7060603@fud.no> Message-ID: <537B0898.8010807@go6.si> On 20/05/14 02:06, Tore Anderson wrote: >> Now it would be eating our own dog food if there were a RIPE BCP >> publication that states that the best way to provide IPv4 on a modern >> wifi is NAT64. However, as far as I know, there is no such document, >> no plans for it, and I would be surprised major wifi hotspot would >> want to move to 464XLAT. But you never know. > > We are talking about the RIPE meeting here, not a random wifi hotspot at > your local coffee shop or wherever. We're the ones actually insisting > that others to go do this IPv6 thing, so we should really be at the > forefront of such efforts ourselves. If the BCP you're describing is to > ever be written, we can't expect that a coffee shop, airport or whatever > will provide the deployment experience on which such a document could be > based - the RIPE meeting, on the other hand, would be a perfect fit. Hey, I think the next step would be to leave IPv6 + IPv4 on main RIPE-MTG wifi network, but instead of DNS to start provisioning DNS64 by default. That's what I'm doing majority of the time and it works flawlessly. What would this mean - DNS64 would return A and AAAA record for *every* query (unless the queried name is IPv6-only) and lot's of today IPv4 traffic would shift to IPv6+NAT64 and give us the opportunity to observe how all this works on a larger scale... Whichever legacy app that does not support IPv6 might be used by attendees - it would still work using IPv4 transport. There were networks and events where we "secretly" started to insert DNS64 instead a normal DNS- we called that an experiment - and people did not even notice ;) Cheers, Jan From jan at go6.si Tue May 20 09:53:38 2014 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 20 May 2014 09:53:38 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: <537B0898.8010807@go6.si> References: <5378715B.2030906@fud.no> <537A9C75.7060603@fud.no> <537B0898.8010807@go6.si> Message-ID: <537B0A02.7030605@go6.si> On 20/05/14 09:47, Jan Zorz @ go6.si wrote: > I think the next step would be to leave IPv6 + IPv4 on main RIPE-MTG > wifi network, but instead of DNS to start provisioning DNS64 by default. > > That's what I'm doing majority of the time and it works flawlessly. ah, BTW, in go6lab we are running currently open test of NAT64 implementations, currently we have 3 setups that uses public NAT64 prefix and can be tested from the Internet. Feel free to use them and test and please report back your findings. Maybe we can start another operational document on NAT64 that can go through BCOP/IPv6-WG path... http://go6lab.si/current-ipv6-tests/nat64dns64-public-test/ cheers, Jan From marcoh at marcoh.net Tue May 20 10:13:57 2014 From: marcoh at marcoh.net (Marco Hogewoning) Date: Tue, 20 May 2014 10:13:57 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: <537B0898.8010807@go6.si> References: <5378715B.2030906@fud.no> <537A9C75.7060603@fud.no> <537B0898.8010807@go6.si> Message-ID: > I think the next step would be to leave IPv6 + IPv4 on main RIPE-MTG wifi network, but instead of DNS to start provisioning DNS64 by default. Just to straighten out things, I am happy to see if we can work together with IT/Ops to progress the current ?IPv6 Only Experimental? setup to something less experimental. As per Jen?s suggestion, happy to see if we can get the name changed and while keeping it as a best effort service, see if we can work in slowly bringing this under supervision of the IT department. In fact, as I mentioned in the closing plenary, during setup we already received a lot of support from the RIPE NCC. Razvan and his crew spend quite a bit of time with Andrew to get things running without any additional hardware. Everything you have been using last week lived on RIPE NCC hardware and it all just switches on and off together with the main network. I don?t think it is feasible and I?m simply opposing to changing anything on the regular meeting setup. I fully agree that we should eat our own dog food, but I also don?t believe in forcing it down peoples throat. Over the years even small disruptions in network connectivity have lead to numerous complaints, both in public statements during plenary sessions as well as behind the scenes and on social media. There apparently is a large group of attendees who depend on connectivity or at least believe that they depend on it. This btw is not unique to RIPE Meetings, I?ve observed similar issues in venues such as IETF. And it is all fine, over the years the IT team has done a great job in providing a network that serves all and at very high service levels. Keep in mind that this all lives in flight cases and is installed on the venue in pretty much 48 hours. I?ve worked in the industry myself for a few years and never seen a greenfield network getting up and running towards somewhere in the 4 nines range as this one. In simple terms, I don?t want to take the risk. As much as I have confidence in the IT team that will deliver, any small glitch will be looked upon and eventually IPv6 (and this working group) will get the blame. We know stuff doesn?t work and there will be people who walk into the meeting who are not aware of what is going on and who will have a bad experience. There are about 25% newcomers at every meeting who may or may not be aware. I would rather provide them a setup where they can try and test at their own convenience and pace, rather than at some critical moment find out stuff doesn?t work and scramble for a backup solution. That being said, no promises yet. I?ll plan a meeting with the IT team to find out how they feel about this and what is possible. But for now I am not going to suggest to touch on any of the regular meeting setup and suggest to keep the L2 separation as it is, including the preferences. Marco (no hats, my own opinion, I?m just as much a ?customer? as you all are) From gert at space.net Tue May 20 10:20:22 2014 From: gert at space.net (Gert Doering) Date: Tue, 20 May 2014 10:20:22 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: References: <5378715B.2030906@fud.no> <537A9C75.7060603@fud.no> <537B0898.8010807@go6.si> Message-ID: <20140520082022.GS46558@Space.Net> Hi, On Tue, May 20, 2014 at 10:13:57AM +0200, Marco Hogewoning wrote: > In simple terms, I don?t want to take the risk. Wouldn't it be much more safe to completely turn off IPv6 on the meeting LAN, then? And WiFi, as wired ethernet is way more reliable anyway. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From marcosommani at gmail.com Tue May 20 08:45:36 2014 From: marcosommani at gmail.com (Marco Sommani) Date: Tue, 20 May 2014 08:45:36 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: <537A9C75.7060603@fud.no> References: <5378715B.2030906@fud.no> <537A9C75.7060603@fud.no> Message-ID: <4ADCA7E6-2AC1-4646-86CB-EC4E0171FF11@gmail.com> On 20/mag/2014, at 02:06, Tore Anderson wrote: > * Philip Homburg > >> Note, I'm talking about the proposal to make the detault meeting >> network support 464XLAT. I don't think there is any proposal to make >> the default meeting network IPv6-only (i.e. without any support for >> IPv4) > > I don't think you can say that "the network support supports 464XLAT" > as 464XLAT consists of two components, of which only one (the PLAT, or > in other words the NAT64 gateway) is implemented in the network. The > other component, the CLAT, is located on the end-user device itself. Not necessarily. This picture, taken from rfc6877, shows the general 464XLAT scenario: +------+ | v6 | | host | +--+---+ | .---+---. / \ / IPv6 \ | Internet | \ / `----+----' | +------+ | .---+---. .------. | v6 +---+ +------+ / \ +------+ / \ | host | | | | / IPv6 \ | | / IPv4 \ +------+ +---+ CLAT +---+ Network +---+ PLAT +---+ Internet | +--------+ | | | \ / | | \ / | v4p/v6 +-+ +------+ `---------' +------+ `----+----' | host | | | +--------+ | +--+---+ +------+ | | v4g | | v4p +---+ | host | | host | | +------+ +------+ | <- v4p -> XLAT <--------- v6 --------> XLAT <- v4g -> v6 : Global IPv6 v4p : Private IPv4 v4g : Global IPv4 Figure 1: Wireline Network Topology The CLAT must not necessarily stay on end-user devices, because it may also be in a box at the border of a dual-stack customer network. On the other hand, I have to agree that this setup is useless for the purpose of offering to participants the experience of an IPv6-only world (actually, they would continue to experience dual-stack). On the other hand, this setup could be useful to convince the operators that, even if they eliminate IPv4 from their backbones, their customers may still continue to have IPv4 as usual. -- Marco Sommani Via Contessa Matilde 64C 56123 Pisa - Italia phone: +390500986728 mobile: +393487981019 fax: +390503869728 email: marcosommani at gmail.com From tore at fud.no Tue May 20 10:43:10 2014 From: tore at fud.no (Tore Anderson) Date: Tue, 20 May 2014 10:43:10 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: <8C166CDC-BFB0-49AC-8BFD-DB12C4F99AAD@cnr.it> References: <5378715B.2030906@fud.no> <537A9C75.7060603@fud.no> <8C166CDC-BFB0-49AC-8BFD-DB12C4F99AAD@cnr.it> Message-ID: <537B159E.8010101@fud.no> * Marco Sommani > On 20/mag/2014, at 02:06, Tore Anderson wrote: > >> The other component, the CLAT, is located on the end-user device >> itself. > > The CLAT must not necessarily stay on end-user devices, because it > may also be in a box at the border of a dual-stack customer network. The only sensible location for the CLAT in the wireline topology is on the CPE - which *is* an end-user device, as far as I'm concerned. :-) > On the other hand, I have to agree that this setup is useless for > the purpose of offering to participants the experience of an > IPv6-only world (actually, they would continue to experience > dual-stack). Indeed. While I suppose it is technically possible to contain a complete 464XLAT topology entirely within in the core of provider network (including the RIPE meeting infrastructure "core"), that would strike me as a utterly pointless exercise. Tore From marcoh at marcoh.net Tue May 20 10:47:39 2014 From: marcoh at marcoh.net (Marco Hogewoning) Date: Tue, 20 May 2014 10:47:39 +0200 Subject: [ipv6-wg] IPv6 only network at RIPE 68 In-Reply-To: <20140520082022.GS46558@Space.Net> References: <5378715B.2030906@fud.no> <537A9C75.7060603@fud.no> <537B0898.8010807@go6.si> <20140520082022.GS46558@Space.Net> Message-ID: <18A182DC-AB58-49C5-B567-EEA88F992480@marcoh.net> > Hi, > > On Tue, May 20, 2014 at 10:13:57AM +0200, Marco Hogewoning wrote: >> In simple terms, I don?t want to take the risk. > > Wouldn't it be much more safe to completely turn off IPv6 on the meeting > LAN, then? And WiFi, as wired ethernet is way more reliable anyway. I don;t think the issues right now are with IPv6 per se, what I?ve seen so far it is the lack of IPv4 that is causing issues. Just a random list if what comes to mind right now: - Android sucks in multiple dimensions - Skype does not work - Every time OS X restarts the dhcp-client (on exponential back off), it sends signal that makes my VPN client believe it lost connectivity and causes it to drop all sockets and reconnect. I can assume other people will get hit by at least some of the above and there are of course others. Forcing people, who might not be able to do something about this or implement work arounds, to use this or by default give them something that we know is broken should (?must??) be considered bad practice. In the long run this is likely to cause damage to the reputation of IPv6 in general or RIPE NCC. ?I switched to the IPv4 and it al works, so IPv6 still suck golfballs through a garden hose? Marco From sandra.sendra.upv at gmail.com Tue May 20 11:15:27 2014 From: sandra.sendra.upv at gmail.com (Sandra Sendra) Date: Tue, 20 May 2014 11:15:27 +0200 Subject: [ipv6-wg] IEEE International Workshop on Cloud-integrated Cyber Physical Systems 2014 (IEEE Cloud-CPS 2014) Message-ID: <201405200915.s4K9FR8q021653@smtp.upv.es> ********************************************************* CALL FOR PAPERS IEEE International Workshop on Cloud-integrated Cyber Physical Systems 2014 (IEEE Cloud-CPS 2014) Submission due July 31, 2014 http://cloudcps.cwins.org Dec 15 ? 18, 2014, Singapore Singapore in conjunction with IEEE CloudCom 2014, Dec 15 ? 18, 2014, Singapore ******************************************************************** Technology has gone through tremendous changes in terms of computing, communications and control to provide wide range of applications in all domains. This advancement provides the opportunities to bridge the physical components/processes and the cyber space leading to the Cyber Physical Systems (CPS). The notion of CPS is to use computing (sensing, analyzing, predicting, understanding, etc.), communication (interaction, intervene, interface management, etc.) and control (inter-operate, evolve, evidence-based certification, etc.) to make intelligent and autonomous systems. Such systems are playing an increasingly prevalent and important role in this electronic era such as healthcare, manufacturing, civil infrastructure, aerospace, entertainment, transportation and many automated physical systems. Computing and networking are two major components of CPS and Cloud has infinite resources for both. Cloud-integrated CPS will not only enhance CPS itself but also process, analyze! and manage (CPS) big data efficien tly. However, there are many issues and hurdles of Cloud-integrated CPS that need discussions. Our aim is to provide a platform for researchers and practitioners to present their research results in the area of Cloud-integrated Cyber-Physical Systems. The proposed workshop CloudCPS-2014 will serve as a forum for researchers from academia, government and industries to exchange ideas, present new results and provide future visions on these topics. Topics of interest include but not limited to: - Cloud-CPS Architecture - Cloud-CPS Modeling and Simulation - Virtualization of Physical Components in Cloud-CPS - Design and Performance Optimization in Cloud-CPS - Cloud-assisted Situation-aware and decision support - Big-data Processing and Visualization in Cloud-CPS - Mobile Cloud-CPS - Game Theory for Cloud-CPS - Tools and Methods for Cloud-CPS - Sensor-actuator Networks - Security, Privacy, and Trust in Cloud-CPS - Intelligent (Road/Air) Transportation Cloud-CPS - Cloud-CPS in healthcare - Cloud-CPS in energy - Fog computing - Cloud-CPS: Tools, test beds and deployment issues - Opportunistic spectrum access for Cloud-CPS ***************************** SUBMISSION INSTRUCTIONS ***************************** The authors are advised to submit their research paper following the IEEE CS format: two columns, single-spaced, including figures and references, using 10 fonts, and number each page. Instructions for authors how to format the manuscript can be found at: http://www.computer.org/portal/web/cscps/submission/ http://www.computer.org/portal/web/cscps/formatting/ The following templates below, are general templates designed for conferences using an US Letter (8.5" x 11") trim size. MS Word Template: http://www.computer.org/portal/c/document_library/get_file?uuid=4cc57ba2-393e-4a04-9551-3a45535c5198&groupId=525773 LaTeX Package: http://www.computer.org/portal/c/document_library/get_file?uuid=cda2f9b2-516f-43b8-ba8d-da91c0503dac&groupId=525773 Papers will be carefully evaluated based on originality, significance, technical soundness, and clarity of exposition. The papers, in pdf format, should be submitted electronically through https://www.easychair.org/conferences/?conf=ieeecloudcps2014. If there is any problem during submission, please contact the workshop general chairs or db.rawat(at)ieee.org. All accepted papers will be published by IEEE CS Press (submitted to IEEEXplore) and submitted for indexing by EI and ISSN. *********************** Important Dates *********************** Deadline for paper submissions: July 31, 2014 Notification of Paper acceptance: Sept. 2, 2014 Deadline for camera-ready: Sept.16, 2014 Deadline for author registration: Oct. 1, 2014 Conference: December 15-18, 2014 WORKSHOP WEBSITE For more information, please visit the workshop website at http://cloudcps.cwins.org ++++++++++++++++ Organizers ++++++++++++++++ **************** General Chairs **************** Ivan Stojmenovic, University of Ottawa, Canada Danda B. Rawat, Georgia Southern University, USA Jaime Lloret Mauri, Polytechnic University of Valencia, Spain ****************** Program Chairs ****************** Bhed B. Bista, Iwate Prefectural University, Japan Song Guo, The University of Aizu, Japan ******************* Publicity Chairs ******************* Sandra Sendra, Polytechnic University of Valencia, Spain From alexb at ripe.net Tue May 20 17:07:26 2014 From: alexb at ripe.net (Alex Band) Date: Tue, 20 May 2014 17:07:26 +0200 Subject: [ipv6-wg] Introducing the IPv6 Analyser Message-ID: <4E325924-7C5F-4429-9AFB-980CB1F4DAF2@ripe.net> Dear colleagues, You can now visit the LIR Portal and try out seamless RIPE Database object creation using the IPv6 Analyser: https://www.ripe.net/s/zToA The IPv6 Analyser is a toolset that offers our members a visual insight into all the allocations, aggregations and assignments they have made. This is the first toolset that seamlessly integrates with the RIPE Database, allowing you to create new objects with an easy-to-use wizard that guides you through the process, searching for available space, and pre-filling known information. Our goal is to unify resource management in the LIR Portal by extending these design principles to organisation, routing and Reverse DNS management. Now that the core design is available, we very much look forward to your feedback on how we can make the IPv4 and IPv6 Analyser as useful as possible. Kind regards, Alex Band Product Manager RIPE NCC From benno at NLnetLabs.nl Wed May 21 13:43:06 2014 From: benno at NLnetLabs.nl (Benno Overeinder) Date: Wed, 21 May 2014 13:43:06 +0200 Subject: [ipv6-wg] Vacancy - nominations can go here In-Reply-To: References: <82D2713E-9B05-4C95-85CF-918D94A4DA4C@marcoh.net> Message-ID: <537C914A.6090402@NLnetLabs.nl> I would like to support the nomination of Jen Linkova. I think she would be an excellent co-chair. As I have learned Jen, she has an in-depth knowledge of the IPv6 protocol, and also knows of deployment and operational issues (why things don't work as expected). She is curious and investigating, and an energetic person to collaborate with. Regards, -- Benno On 15/05/14 14:36, Jen Linkova wrote: > Thanks Marco for starting the thread! > > I'd like to volunteer for this role and I'd be happy to do my best to > help the WG, the community and the global IPv6 deployment ;) > > > On Thu, May 15, 2014 at 12:58 PM, MarcoH wrote: >> Hi, >> >> As just mentioned, we are looking for new co-chairs for the IPv6 Working Group. >> >> If you need more info of what is involved feel free to ask Shane or me. >> >> We will send a more lengthy mail regarding process later. In the meantime we welcome nominations. >> >> For consistency, please reply to this thread so all nominations are grouped. >> >> MarcoH >> -- >> Sent from mobile, sorry for the typos > > -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/ From willem at nlnetlabs.nl Wed May 21 13:58:01 2014 From: willem at nlnetlabs.nl (Willem Toorop) Date: Wed, 21 May 2014 13:58:01 +0200 Subject: [ipv6-wg] Vacancy - nominations can go here In-Reply-To: <537C914A.6090402@NLnetLabs.nl> References: <82D2713E-9B05-4C95-85CF-918D94A4DA4C@marcoh.net> <537C914A.6090402@NLnetLabs.nl> Message-ID: <537C94C9.1070900@nlnetlabs.nl> I full heartedly concur. Douze points pour Jen Linkova. -- Willem op 21-05-14 13:43, Benno Overeinder schreef: > I would like to support the nomination of Jen Linkova. > > I think she would be an excellent co-chair. As I have learned Jen, she > has an in-depth knowledge of the IPv6 protocol, and also knows of > deployment and operational issues (why things don't work as expected). > She is curious and investigating, and an energetic person to collaborate > with. > > Regards, > > -- Benno > > > On 15/05/14 14:36, Jen Linkova wrote: >> Thanks Marco for starting the thread! >> >> I'd like to volunteer for this role and I'd be happy to do my best to >> help the WG, the community and the global IPv6 deployment ;) >> >> >> On Thu, May 15, 2014 at 12:58 PM, MarcoH wrote: >>> Hi, >>> >>> As just mentioned, we are looking for new co-chairs for the IPv6 Working Group. >>> >>> If you need more info of what is involved feel free to ask Shane or me. >>> >>> We will send a more lengthy mail regarding process later. In the meantime we welcome nominations. >>> >>> For consistency, please reply to this thread so all nominations are grouped. >>> >>> MarcoH >>> -- >>> Sent from mobile, sorry for the typos >> >> > > From joao at bondis.org Wed May 21 15:05:29 2014 From: joao at bondis.org (=?iso-8859-1?Q?Jo=E3o_Damas?=) Date: Wed, 21 May 2014 15:05:29 +0200 Subject: [ipv6-wg] Vacancy - nominations can go here In-Reply-To: <537C914A.6090402@NLnetLabs.nl> References: <82D2713E-9B05-4C95-85CF-918D94A4DA4C@marcoh.net> <537C914A.6090402@NLnetLabs.nl> Message-ID: <32ED1772-82D9-4443-A8D5-C17E289080D4@bondis.org> let me add my voice to benno's, for the same reasons Joao On 21 May 2014, at 13:43, Benno Overeinder wrote: > I would like to support the nomination of Jen Linkova. > > I think she would be an excellent co-chair. As I have learned Jen, she > has an in-depth knowledge of the IPv6 protocol, and also knows of > deployment and operational issues (why things don't work as expected). > She is curious and investigating, and an energetic person to collaborate > with. > > Regards, > > -- Benno > > > On 15/05/14 14:36, Jen Linkova wrote: >> Thanks Marco for starting the thread! >> >> I'd like to volunteer for this role and I'd be happy to do my best to >> help the WG, the community and the global IPv6 deployment ;) >> >> >> On Thu, May 15, 2014 at 12:58 PM, MarcoH wrote: >>> Hi, >>> >>> As just mentioned, we are looking for new co-chairs for the IPv6 Working Group. >>> >>> If you need more info of what is involved feel free to ask Shane or me. >>> >>> We will send a more lengthy mail regarding process later. In the meantime we welcome nominations. >>> >>> For consistency, please reply to this thread so all nominations are grouped. >>> >>> MarcoH >>> -- >>> Sent from mobile, sorry for the typos >> >> > > > -- > Benno J. Overeinder > NLnet Labs > http://www.nlnetlabs.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From maximilian.weigmann at iiv.de Wed May 21 21:32:38 2014 From: maximilian.weigmann at iiv.de (Weigmann Maximilian) Date: Wed, 21 May 2014 21:32:38 +0200 Subject: [ipv6-wg] Follow-Up on Niall's talk: Ramond (RA Monitoring Daemon) In-Reply-To: <87zjiet4uy.fsf@stepladder-it.com> References: <877g5n3ylr.fsf@stepladder-it.com> <20140516153800.GH10353@ernw.de> <878uq090l2.fsf@stepladder-it.com> <0CF0349D-AF9D-441E-AE1E-774339D6C018@ecs.soton.ac.uk> <87zjiet4uy.fsf@stepladder-it.com> Message-ID: <1400700758.3366.16.camel@wmh43> Hi list members, i worked with nav the last three months in an environment with many vlans. With the virtual appliance you only have to prepare your files for the seed database. The whole process can be done in one day - in my experience. The results including prefixes, network map, ... are worth the effort. As stated - it's not a small tool - but the web interface let you get to results quickly. Greetings to All Max Am Montag, den 19.05.2014, 10:55 +0000 schrieb Benedikt Stockebrand: > Hi Tim and list, > > Tim Chown writes: > > >> That seems to be quite the beast. It sounds interesting, but it may be > >> way overkill if you only want to use it to monitor ND. > > > > The point is that NAV does many very useful functions for an > > enterprise. [...] > > that's what I meant. It has a whole pile of interesting features, but > if all you want is ND monitoring *only*, then it may be overkill. > > > Cheers, > > Benedikt > From dez at otenet.gr Thu May 22 10:54:03 2014 From: dez at otenet.gr (Yannis Nikolopoulos) Date: Thu, 22 May 2014 11:54:03 +0300 Subject: [ipv6-wg] Resignation as co-chair of ipv6 In-Reply-To: References: Message-ID: <537DBB2B.50805@otenet.gr> On 05/14/2014 09:02 AM, David Kessens wrote: > Hi, > > My personal circumstances have changed in such a way that I > most recently did not spent as much time and effort for the ipv6 > working group as it deserves. At the same time, I have served the > working group for over 15 years and it would certainly not be unreasonable > to think that it is good for the working group to change direction. > > Considering the above, I have decided to resign as co-chair of the ipv6 > working group. I hope that this change will give a chance to a new > generation of RIPE participants to play a role as a chairperson of a > working > group and as a participant in the RIPE working group chair collective. > > Thanks, > > David Kessens > --- David, thanks very much for the all the contribution to the wg :) cheers, Yannis From dez at otenet.gr Thu May 22 11:07:49 2014 From: dez at otenet.gr (Yannis Nikolopoulos) Date: Thu, 22 May 2014 12:07:49 +0300 Subject: [ipv6-wg] Vacancy - nominations can go here In-Reply-To: <1D614855-EEBA-4738-9100-1D27F7EBC8D3@marcoh.net> References: <1D614855-EEBA-4738-9100-1D27F7EBC8D3@marcoh.net> Message-ID: <537DBE65.5010304@otenet.gr> I'm confused. Are you (Marco) and Shane also going to (eventually) step down? I hope not. Also, about the right number of co-chairs, I think 2 is the one, but 3 seems to work for this WG. cheers, Yannis On 05/18/2014 11:00 AM, Marco Hogewoning wrote: > Please wait a bit :) > > a) there might be others > b) as much as we don?t like overhead, let?s come up with some procedure > c) I need to have a chat with Shane on exactly how we are going to do this > > I had several people including one of the candidates asking for a soft landing, where Shane and I gradually remove ourselves out of this, rather than just running off. So at a minimum we need to fix this in terms of timelines. > > Also it is not a given that there must be three, I think 4 is too many and you definitely need 2 for redundancy. > > First question to the group: how many working group chairs do you want in the end? > > Thanks, > > Marco > > > On 17 mei 2014, at 19:53, Roger J?rgensen wrote: > >> On Sat, May 17, 2014 at 7:37 PM, Jan Zorz @ go6.si wrote: >> >>> But now we've got 3 very good candidates - Jen, Dave and Benedikt - and I >>> think we should rotate them in. >> Excellent suggestion, let's rotate Jen, Dave and Benedikt in. >> >> >> >> -- >> >> Roger Jorgensen | ROJO9-RIPE >> rogerj at gmail.com | - IPv6 is The Key! >> http://www.jorgensen.no | roger at jorgensen.no >> > From jan at go6.si Thu May 22 11:35:25 2014 From: jan at go6.si (Jan Zorz @ go6.si) Date: Thu, 22 May 2014 11:35:25 +0200 Subject: [ipv6-wg] [bcop] BCOP presentation at RIPE meeting in Warsaw In-Reply-To: References: <53467548.9050407@go6.si> Message-ID: <537DC4DD.5020907@go6.si> [now with IPv6 WG address in cc:, actually] On 15/05/14 00:57, Jen Linkova wrote: > Hi Jan, > > finally I've managed to summarize my comments to the doc ;) Hi, thank you very much for all your comments. I'm bringing part of this discussion to IPv6 WG mailing list as it is of technical nature and I think it belongs here. I put all your comments in our issues tracker, reachable publicly at https://git.steffann.nl/go6/ipv6-troubleshooting-for-helpdesks/issues > 1) You suggest to have a local mirror of the test-ipv6. While it > definitely makes sense, using the local mirror might hide some edge > connectivity issues so it worth mentioning. We might recommend to use > *both*. Yes, absolutely. This diversity would also help the ISP to understand if he has any IPv6 issues in other parts of the network other than access ;) > > 2) Section 5 > You provide detailed instruction on how to run ping, but then saying > just 'check DNS settings' and even 'configure different servers' - > support engineers who need explanations on ping, would need more > detailed explanations on how to change DNS settings. > > "If IPv4 is working but the page is unavaliable' - I'd assume that an > engineer could not tell if 'IPv4 is working'. So IMHO we shall just > say that if site is unreachange - troubleshoot as any other 'I can not > open this page' v4-only case. > If we believe that troubleshooting such case is in scope of this > document, I'd suggest to include traceroute as a troubleshooting step. seems as a good idea. let us think about that ;) > > 3) Helpdesk code section: > I'd use different fonts/color to distinguish between 'fixed' and > 'example' fields in the output. > > 4) Code 112 (v4 + broken Ipv6) > > - can we show the process as a flowchart? if-then-else? that's a bit hard one... do we have anybody specialized in flowcharts here? > For example, the doc says 'determine if Ipv6 is offered'. I'd add 'if > it is not,, the customer either has a misconfigured CPE (which has > IPv6 enables while it should not), or there is other Ipv6-enabled > device which is used as a router. Check CPE configuration/state for > IPv6 and disable it if it has it enabled'. > > - I'd re-phrase step 2 as smth like 'if IPv6 is offered to the > customer and you manage their CPE, check if CPE has a approved > firmware version. Upgrade it if it does not'. > > - I'd say that grep (to find the IPv6 address on MacOS) should be > 'grep -E "en|inet6" so interface name is visible (to avoid the scnario > when addresses are assigned to wrong interface); > > - the IPv6 addresses table is a little bit confusing: > -- it contains 6to4 case which should not cause code 112 (as well as > Teredo case); > -- some sections say 'call theor router vendor for support'. I > believe we shall clarify somewhere in the beginning of the document > that we assume that the support deals with customers CPE and if it is > not a case, those CPE-related instructions should be either 'escalate' > or 'advise customer to contact their router vendor for support' (which > in my reality would never happen.....:) > -- as each section of the tabel has instructions (and the last row > says 'escalate', it is not clear in which case the engieer should > proceed to the next step (checking the home router config). > > the section of home router config check is a little bit confusing. > When we just say 'check the configuration of the device', it does not > mean much as we don't specify what we are looking for. Maybe we shall > say smth like: > - 'if CPE is managed by your support, check if CPE is configured as > per your internal documentation' (as we might say somewhere in the doc > that in that case it is strongly recommended to have a separate how-to > on what should be configured on those CPEs); > - check if the LAN interface has IPv6 address from the ISP allocated range; > - check on user device if it has routers's both link-local (fe80:...) > and ISP-assigned address in the neighbor discovery cache ( commands); > - check the routing table on the user's device; see if the default > route points to the router's address. If not - check if DHCP and or > RAs are enabled on the home router. > - run ipv6 traceroute to isp.test-ipv6 site and see where the traceroure stops. I think this are all good suggestions. We'll go through them during our authosr edit cycle meeting, probably during the IETF meeting in Toronto. > > > Code 46 Section > - I'd sugegst to run traceroute to see where it stops. If traceroute > does not show any issues - escalate. If it does outside of your > network - contact the affected netwokr NOC. ack... > > > IMHO a section should be added which explains what kind of information > should be collected for an escalation. I'd suggest: > - Ipv4 and Ipv6 traceroute; > - ifconfig output > - routing table output > - maybe packet capture for the session which is having issues. I think this is asking a bit too much to a first level helpdesk employee... I don't know... Cheers, Jan From marcoh at marcoh.net Thu May 22 11:37:32 2014 From: marcoh at marcoh.net (Marco Hogewoning) Date: Thu, 22 May 2014 11:37:32 +0200 Subject: [ipv6-wg] Vacancy - nominations can go here In-Reply-To: <537DBE65.5010304@otenet.gr> References: <1D614855-EEBA-4738-9100-1D27F7EBC8D3@marcoh.net> <537DBE65.5010304@otenet.gr> Message-ID: Yes, The plan is to replace all of us, but we will create some overlap to provide continuity and some institutional memory to the new group. So please stay tuned for a more detailed plan and timelines, which we can hopefully produce and present to the working group for approval in the coming weeks. Grtx, MarcoH -- "Life is like riding a bicycle. To keep your balance you must keep moving" -- Albert Einstein On 22 May 2014, at 11:07, Yannis Nikolopoulos wrote: > I'm confused. Are you (Marco) and Shane also going to (eventually) step down? I hope not. > Also, about the right number of co-chairs, I think 2 is the one, but 3 seems to work for this WG. > > cheers, > Yannis > > On 05/18/2014 11:00 AM, Marco Hogewoning wrote: >> Please wait a bit :) >> >> a) there might be others >> b) as much as we don?t like overhead, let?s come up with some procedure >> c) I need to have a chat with Shane on exactly how we are going to do this >> >> I had several people including one of the candidates asking for a soft landing, where Shane and I gradually remove ourselves out of this, rather than just running off. So at a minimum we need to fix this in terms of timelines. >> >> Also it is not a given that there must be three, I think 4 is too many and you definitely need 2 for redundancy. >> >> First question to the group: how many working group chairs do you want in the end? >> >> Thanks, >> >> Marco >> >> >> On 17 mei 2014, at 19:53, Roger J?rgensen wrote: >> >>> On Sat, May 17, 2014 at 7:37 PM, Jan Zorz @ go6.si wrote: >>> >>>> But now we've got 3 very good candidates - Jen, Dave and Benedikt - and I >>>> think we should rotate them in. >>> Excellent suggestion, let's rotate Jen, Dave and Benedikt in. >>> >>> >>> >>> -- >>> >>> Roger Jorgensen | ROJO9-RIPE >>> rogerj at gmail.com | - IPv6 is The Key! >>> http://www.jorgensen.no | roger at jorgensen.no From shane at time-travellers.org Thu May 22 11:41:45 2014 From: shane at time-travellers.org (Shane Kerr) Date: Thu, 22 May 2014 11:41:45 +0200 Subject: [ipv6-wg] All Current Chairs Stepping Down (was Re: Vacancy - nominations can go here) In-Reply-To: <537DBE65.5010304@otenet.gr> References: <1D614855-EEBA-4738-9100-1D27F7EBC8D3@marcoh.net> <537DBE65.5010304@otenet.gr> Message-ID: <20140522114145.3f216d9d@luna.home.time-travellers.org> Marco, I just re-read the thread and I realize that we were not clear. David has stepped down as IPv6 co-chair. Marco and I intend to step down over the next few meetings. Neither of us works full-time with IPv6, and we have both been acting as IPv6 co-chairs for a few years. It's time for new people. We'll make sure the working group is well cared-for, no worries. Cheers, -- Shane On Thu, 22 May 2014 12:07:49 +0300 Yannis Nikolopoulos wrote: > I'm confused. Are you (Marco) and Shane also going to (eventually) > step down? I hope not. > Also, about the right number of co-chairs, I think 2 is the one, but > 3 seems to work for this WG. > > cheers, > Yannis > > On 05/18/2014 11:00 AM, Marco Hogewoning wrote: > > Please wait a bit :) > > > > a) there might be others > > b) as much as we don?t like overhead, let?s come up with some > > procedure c) I need to have a chat with Shane on exactly how we are > > going to do this > > > > I had several people including one of the candidates asking for a > > soft landing, where Shane and I gradually remove ourselves out of > > this, rather than just running off. So at a minimum we need to fix > > this in terms of timelines. > > > > Also it is not a given that there must be three, I think 4 is too > > many and you definitely need 2 for redundancy. > > > > First question to the group: how many working group chairs do you > > want in the end? > > > > Thanks, > > > > Marco > > > > > > On 17 mei 2014, at 19:53, Roger J?rgensen wrote: > > > >> On Sat, May 17, 2014 at 7:37 PM, Jan Zorz @ go6.si > >> wrote: > >>> But now we've got 3 very good candidates - Jen, Dave and Benedikt > >>> - and I think we should rotate them in. > >> Excellent suggestion, let's rotate Jen, Dave and Benedikt in. > >> > >> > >> > >> -- > >> > >> Roger Jorgensen | ROJO9-RIPE > >> rogerj at gmail.com | - IPv6 is The Key! > >> http://www.jorgensen.no | roger at jorgensen.no > >> > > > > > From sandra.sendra.upv at gmail.com Wed May 28 12:30:15 2014 From: sandra.sendra.upv at gmail.com (Sandra Sendra) Date: Wed, 28 May 2014 12:30:15 +0200 Subject: [ipv6-wg] Special Issue on "Underwater Sensor Networks" in (JSAN) Message-ID: <201405281030.s4SAUEsC026178@smtp.upv.es> =================================================== Journal of Sensor and Actuator Networks (JSAN) Special Issue "Underwater Sensor Networks" http://www.mdpi.com/journal/jsan/special_issues/usn Deadline for manuscript submissions: 30 September 2014 ---------------------------------------------------- === SPECIAL ISSUE === New advances in information technologies, circuits, systems and communication protocols have made possible the deployment of underwater sensor networks. These issues have lead researchers to propose new underwater sensor nodes, sensor node placement, protocols for their communication, architectures, and study new ways to communicate with higher bandwidth at higher distances. Moreover, the range of underwater applications is growing fast because of the last research in oceanography, marine science and aquiculture, so there is a need of underwater sensor networks in order to support these disciplines. This special Issue is tries to collect unpublished works on theory and practice on underwater sensor networks, with special interest on real implementations and deployments. We also seek new proposals on wireless communication technologies. === KEYWORDS === The Special Issue "Underwater Sensor Networks" topics include (but are not limited to) the following: - Underwater sensor nodes - Underwater sensor node placement - Routing protocols for underwater sensor networks - Underwater communications - Underwater architectures - Underwater wireless communications - Underwater sensor network deployments === SUBMISSION === Manuscripts should be submitted online at www.mdpi.com by registering and logging in to this website. Once you are registered, click here to go to the submission form (http://www.mdpi.com/user/manuscripts/upload/?journal=jsan). Manuscripts can be submitted until the deadline. Papers will be published continuously (as soon as accepted) and will be listed together on the special issue website. Research articles, review articles as well as communications are invited. For planned papers, a title and short abstract (about 100 words) can be sent to the Editorial Office for announcement on this website. Submitted manuscripts should not have been published previously, nor be under consideration for publication elsewhere (except conference proceedings papers). All manuscripts are refereed through a peer-review process. A guide for authors and other relevant information for submission of manuscripts is available on the Instructions for Authors page. Journal of Sensor and Actuator Networks is an international peer-reviewed Open Access quarterly journal published by MDPI. Please visit the Instructions for Authors page (http://www.mdpi.com/journal/jsan/instructions) before submitting a manuscript. For the first couple of issues the Article Processing Charge (APC) will be waived for well-prepared manuscripts. English correction and/or formatting fees of 250 CHF (Swiss Francs) will be charged in certain cases for those articles accepted for publication that require extensive additional formatting and/or English corrections. === SPECIAL ISSUE EDITORS === Guest Editors Prof. Dr. Jaime Lloret Mauri (jlloret at dcom.upv.es) Integrated Management Coastal Research Institute, Polytechnic University of Valencia, Camino de Vera 46022, Valencia, Spain Dr. Sandra Sendra (sansenco at posgrado.upv.es) Integrated Management Coastal Research Institute, Polytechnic University of Valencia, Camino de Vera 46022, Valencia, Spain ===================================================