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
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
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 <zbynek@dialtelecom.cz> 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
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.
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
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.
On Fri, May 16, 2014 at 2:44 PM, Andrew 👽 Yourtchenko <ayourtch@gmail.com>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
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 <marcoh@marcoh.net> 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
On 16 May 2014, at 15:24, Jen Linkova <furry13@gmail.com> 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
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@polsl.pl
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
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@polsl.pl
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
* 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
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@polsl.pl
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?
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
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.
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
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.
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
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
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@swm.pp.se
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
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@swm.pp.se
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
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@swm.pp.se
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)
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
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.
* 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
On 20/mag/2014, at 02:06, Tore Anderson <tore@fud.no> 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@gmail.com
On 20/mag/2014, at 02:06, Tore Anderson <tore@fud.no> 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@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@cnr.it
* Marco Sommani
On 20/mag/2014, at 02:06, Tore Anderson <tore@fud.no> 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
Hi, having the Warsaw wg session in mind I wrote down some thoughts as for potential RIPE 554bis elements on cloud service providers. These can be found here: http://www.insinuator.net/2014/07/ipv6-requirements-for-cloud-service-provid.... Hope someone may find it useful and/or this can re-ignite reflecting on the RIPE 554 successor. have a great weekend everybody Enno -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator =======================================================
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
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
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<dot> 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)
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
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
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
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 <gert@space.net> 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
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?
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
Hi Marco and list, MarcoH <marcoh@marcoh.net> 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/
Marco, On Sat, May 17, 2014 at 8:12 AM, MarcoH <marcoh@marcoh.net> 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
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"
* 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
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 =======================================================
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
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
On Sun, May 18, 2014 at 12:43 PM, Jan Zorz @ go6.si <jan@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
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 <jan@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-Bui... & 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 =======================================================
On Sun, May 18, 2014 at 10:10 AM, Marco Hogewoning <marcoh@marcoh.net> 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
On 18 May 2014 09:10, Marco Hogewoning <marcoh@marcoh.net> 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
Hi Marco and list, Marco Hogewoning <marcoh@marcoh.net> 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@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/
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@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
Hi Marco and list, Marco Hogewoning <marcoh@marcoh.net> 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/
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.
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
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. themselves as v6-only). BR, Zbynek
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 <furry13@gmail.com> 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/
On Fri, May 16, 2014 at 4:24 PM, Jen Linkova <furry13@gmail.com> 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@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no
On Sat, May 17, 2014 at 7:35 PM, Roger Jørgensen <rogerj@gmail.com> wrote:
On Fri, May 16, 2014 at 4:24 PM, Jen Linkova <furry13@gmail.com> 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
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 <rogerj@gmail.com> 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
On Fri, May 16, 2014 at 4:24 PM, Jen Linkova <furry13@gmail.com> wrote: 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
On Sat, May 17, 2014 at 9:34 PM, Elvis Velea <elvis@velea.eu> 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
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 <furry13@gmail.com> wrote:
On Sat, May 17, 2014 at 9:34 PM, Elvis Velea <elvis@velea.eu> 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
On Sat, May 17, 2014 at 9:18 PM, Jen Linkova <furry13@gmail.com> wrote:
On Sat, May 17, 2014 at 7:35 PM, Roger Jørgensen <rogerj@gmail.com> wrote: <snip>
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@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no
participants (23)
-
Aled Morris -
Andrew 👽 Yourtchenko -
Benedikt Stockebrand -
Elvis Daniel Velea -
Elvis Velea
-
Enno Rey -
Gert Doering -
Jan Zorz ＠ go6.si -
Jen Linkova -
Marco Hogewoning -
Marco Sommani -
Marco Sommani -
MarcoH
-
Mick O'Donovan -
Mikael Abrahamsson -
Niall O'Reilly -
Nicolas CARTRON -
Paul Ebersman -
Philip Homburg -
Piotr Strzyzewski -
Roger Jørgensen -
Tore Anderson -
Zbynek Pospichal