Hi, I agree with Ondrej, leave every hint of "experimental" out, of course you could mention that unfortunately not all devices yet support ipv6. Rgds, Ray. -----Original Message----- From: ipv6-wg [mailto:ipv6-wg-bounces@ripe.net] On Behalf Of Gert Doering Sent: 26. lokakuuta 2015 12:03 To: Ond??ej Caletka Cc: ipv6-wg@ripe.net Subject: Re: [ipv6-wg] IPv6-only network during RIPE 71 Hi, On Mon, Oct 26, 2015 at 10:46:02AM +0100, Ond??ej Caletka wrote:

I think the technology is mature enough to be provided as a regular RIPE NCC service during the meeting - that means regular network name and, most important, a password that is propagated in the same way the normal Wi-Fi network password is. This is especially important for the one third of newcomers that have had a big troubles learning the password of the IPV6ONLYEXP network.

After RIPE 70, I proposed a "drastic" approach [1], renaming the dual-stack meeting network to -legacy and promote the NAT64 network as the default. This is the same way they do it on FOSDEM since 2014 [2]. But maybe we could try a slow start first, keeping the dual-stacked network the default and offering the NAT64 network with some suffix like -v6only.

I'm with you that we should no longer market the IPv6-only as "this is an experiment, it will not work, and is unreliable anyway, so use on your own risk!" network. This is what Internet looks like on more and more mobile networks already today - time to get used to it. OTOH, I'm not sure whether it should be default - can Android cope with IPv6-only networks today? If yes, then go for it :-) - if not, maybe not this year... 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 Mon 26 Oct 2015, 11:23, Piotr Strzyzewski wrote:

On Mon, Oct 26, 2015 at 11:02:52AM +0100, Gert Doering wrote:

...

On Mon, Oct 26, 2015 at 10:46:02AM +0100, Ond??ej Caletka wrote:

...

I think the technology is mature enough to be provided as a regular RIPE NCC service during the meeting - that means regular network name and, most important, a password that is propagated in the same way the normal Wi-Fi network password is. This is especially important for the one third of newcomers that have had a big troubles learning the password of the IPV6ONLYEXP network.

After RIPE 70, I proposed a "drastic" approach [1], renaming the dual-stack meeting network to -legacy and promote the NAT64 network as the default. This is the same way they do it on FOSDEM since 2014 [2]. But maybe we could try a slow start first, keeping the dual-stacked network the default and offering the NAT64 network with some suffix like -v6only.

I'm with you that we should no longer market the IPv6-only as "this is an experiment, it will not work, and is unreliable anyway, so use on your own risk!" network. This is what Internet looks like on more and more mobile networks already today - time to get used to it.

+1

...

OTOH, I'm not sure whether it should be default - can Android cope with IPv6-only networks today? If yes, then go for it :-) - if not, maybe not this year...

If not, Android users could use this "-legacy" network the same way like so called "pioneers" use this "experimental" one last time at RIPE Meeting.

What I remember from the last meeting is that often the applications seem to be the problem (Skype, for example). I think the most important thing here is the availability of 'troubleshooting information', so people know where to look in case things don't work. Jen made a list with troublesome applications: if that list is available at the network operation room, it can function as a shortcut. 'Program $X is not working? Try the legacy ssid' And +1 on removing terminology like 'legacy'. luuk

While I am unable to be at RIPE-71, I cannot refrain from wondering why are we so shy/afraid of IPv6... FOSDEM (those layer-7 people) did an IPv6-only (strange name IMHO because it had NAT64), so, why wouldn't a meeting about IP be as assertive about IP? -éric (fool enough to run a dual-stack large conference WiFi with Gert D., Gunter, Andrew and others back in 2010 or even earlier) On 26/10/15 11:35, "ipv6-wg on behalf of Luuk Hendriks" <ipv6-wg-bounces@ripe.net on behalf of luuk.hendriks@utwente.nl> wrote:

On Mon 26 Oct 2015, 11:23, Piotr Strzyzewski wrote:

...

...

On Mon, Oct 26, 2015 at 10:46:02AM +0100, Ond??ej Caletka wrote:

...

I think the technology is mature enough to be provided as a regular RIPE NCC service during the meeting - that means regular network name and, most important, a password that is propagated in the same way the normal Wi-Fi network password is. This is especially important for the one third of newcomers that have had a big troubles learning the

...

...

the IPV6ONLYEXP network.

After RIPE 70, I proposed a "drastic" approach [1], renaming the dual-stack meeting network to -legacy and promote the NAT64 network as the default. This is the same way they do it on FOSDEM since 2014 [2]. But maybe we could try a slow start first, keeping the dual-stacked network the default and offering the NAT64 network with some suffix

On Mon, Oct 26, 2015 at 11:02:52AM +0100, Gert Doering wrote: password of like

...

...

-v6only.

I'm with you that we should no longer market the IPv6-only as "this is an experiment, it will not work, and is unreliable anyway, so use on your own risk!" network. This is what Internet looks like on more and more mobile networks already today - time to get used to it.

+1

...

OTOH, I'm not sure whether it should be default - can Android cope with IPv6-only networks today? If yes, then go for it :-) - if not, maybe not this year...

If not, Android users could use this "-legacy" network the same way like so called "pioneers" use this "experimental" one last time at RIPE Meeting.

What I remember from the last meeting is that often the applications seem to be the problem (Skype, for example). I think the most important thing here is the availability of 'troubleshooting information', so people know where to look in case things don't work. Jen made a list with troublesome applications: if that list is available at the network operation room, it can function as a shortcut. 'Program $X is not working? Try the legacy ssid'

And +1 on removing terminology like 'legacy'.

luuk

+ Marco, Nick On Mon, Oct 26, 2015 at 11:02 AM, Gert Doering <gert@space.net> wrote:

On Mon, Oct 26, 2015 at 10:46:02AM +0100, Ond??ej Caletka wrote:

...

I think the technology is mature enough to be provided as a regular RIPE NCC service during the meeting - that means regular network name and, most important, a password that is propagated in the same way the normal Wi-Fi network password is. This is especially important for the one third of newcomers that have had a big troubles learning the password of the IPV6ONLYEXP network.

After RIPE 70, I proposed a "drastic" approach [1], renaming the dual-stack meeting network to -legacy and promote the NAT64 network as the default. This is the same way they do it on FOSDEM since 2014 [2]. But maybe we could try a slow start first, keeping the dual-stacked network the default and offering the NAT64 network with some suffix like -v6only.

I'm with you that we should no longer market the IPv6-only as "this is an experiment, it will not work, and is unreliable anyway, so use on your own risk!" network. This is what Internet looks like on more and more mobile networks already today - time to get used to it.

OTOH, I'm not sure whether it should be default - can Android cope with IPv6-only networks today?

All new versions (5.x AFAIR) work well, I think I demonstrated it on the last meeting ;)

If yes, then go for it :-) - if not, maybe not this year...

Marco, Nick - what do you think? I definitely see a lot of interest and support in the community for moving IPv6-only network out of the experimental state. Probably moving dual-stack network to legacy this meeting might be bit extreme (we do care about people who do not care about Ipv6 yet, don't we? ;)) and we do not provide bad network experience), but what about stop calling it "experimental" and include it in the list of the standard SSIDs? -- SY, Jen Linkova aka Furry

On 26/10/15 12:12, Sander Steffann wrote:

Proposal: rename the v6-only network to "ripemtg-new" and keep the current "ripemtg" for RIPE71. For RIPE72 (2016!) rename the dual-stack network to "ripemtg-legacy" and the v6-only to "ripemtg".

There will be the legacy network for people/devices/etc that have trouble on IPv6-only. We definitely should make sure we offer workable networking for everybody. But I think it's about time people started realising it explicitly when they need a legacy protocol to keep working.

+1 Cheers, Jan

On Mon, Oct 26, 2015 at 12:12:31PM +0100, Sander Steffann wrote:

Proposal: rename the v6-only network to "ripemtg-new" and keep the current "ripemtg" for RIPE71. For RIPE72 (2016!) rename the dual-stack network to "ripemtg-legacy" and the v6-only to "ripemtg".

There will be the legacy network for people/devices/etc that have trouble on IPv6-only. We definitely should make sure we offer workable networking for everybody. But I think it's about time people started realising it explicitly when they need a legacy protocol to keep working.

Cheers, Sander

Seems ideal to me! +1 -- Mick O'Donovan | Network Engineer | BT Ireland | Website: http://www.btireland.net Looking Glass: http://lg.as2110.net Peering Record: http://as2110.peeringdb.com AS-SET Macro: AS-BTIRE | ASN: 2110

Marco, Nick - what do you think? I definitely see a lot of interest and support in the community for moving IPv6-only network out of the experimental state. Probably moving dual-stack network to legacy this meeting might be bit extreme (we do care about people who do not care about Ipv6 yet, don't we? ;)) and we do not provide bad network experience), but what about stop calling it "experimental" and include it in the list of the standard SSIDs?

Dear Jen, colleagues, We very much appreciate the on going efforts of the IPv6 Working Group to support the deployment of IPv6 and especially for providing people the means to experience an IPv6 only network fist hand. The RIPE NCC IT operations team has been involved from the start of this project and with help from community members, the network setup has evolved and is now mostly integrated with the regular meeting network layout. So far we are happy to note that this parallel operation of an IPv6-only network has not led to any major operational incidents that impacted the availability of any of the RIPE meeting networks. However we did see several reports of issues at clients with OS or client software showing unexpected or erroneous behaviour. We also noted that there is still some confusion amongst attendees regarding the different functionality of the available networks. Our primary concern is that within the resource constraints we have on staff time and expertise, we cannot offer detailed support to end users, who are experiencing problems. We are aware that several techniques exist to remedy some of the expected problems with client software, but these appear not universally available across all clients. Also none of these solutions have been tested in the specific environment of the RIPE meeting network. We have to take into account that RIPE meetings have participants from different backgrounds and with different expertise. People might not be that well versed in the technical background of IPv6, or might not be able to adjust their systems to work correctly in this network setup. Our primary objective is that everybody who attends a RIPE meeting is satisfied with the network quality offered and is able to do his or her work without the need of additional changes, software or detailed support. Taken into account the discussion in this working group, we do agree that labelling the IPv6-only network as “experimental” might have unintended consequences and leave the impression that IPv6 is not ready for deployment. We support the working group in their efforts to change the messaging surrounding this initiative to make it appear less experimental and put more confidence in IPv6 as a technology, which is ready for broad deployment. At the same time we are not assured that an IPv6-only environment will not lead to any problems at the user level, which might be perceived as a problem with the RIPE meeting network. We are happy to work with the community in implementing changes to the network name and documentation and promotion efforts. Our IT staff has confirmed that we can change the name and password without much effort and this can be done prior to RIPE 71. However we must also insist that, at this stage, that there must be no confusion with the primary dual stack network, which is supported by RIPE NCC staff. On an additional note we must warn the community on the use of any relative or subjective names such as “new” and select an alternative that provides a functional description of the network. We invite the community to use this upcoming RIPE meeting to collect further feedback and develop user level documentation on any remaining problems and any possible workarounds that could avoid such issues. We hope that this documentation in turn can form the basis for a discussion with the broader RIPE community on a proposal to change configuration of the primary network and provide confidence that such a change would not lead to any operational problems for RIPE meeting attendees or otherwise have impact on the stability of the RIPE NCC operated infrastructure. We hope to see you all soon in Bucharest, Marco Hogewoning RIPE NCC

On Thu, Oct 29, 2015 at 04:13:45PM +0100, Jan Zorz wrote:

On 29/10/15 11:30, Marco Hogewoning wrote:

...

Our primary concern is that within the resource constraints we have on staff time and expertise, we cannot offer detailed support to end users, who are experiencing problems.

Experience is learned by doing it, right?

On that note: Is anyone collecting data on issues with and performance of the NAT64 network which could be useful information for others planning to deploy this? RIPE Labs? rgds, Sascha Luck

On Sat, Oct 31, 2015 at 1:24 PM, Jen Linkova <furry13@gmail.com> wrote:

As this topic seems to be a hot one for this WG, I'm planning to reserve some time during the WG session in Bucharest for the 'open-mic' discussion.

Correction: this discussion will happen at the end of Wed WG slot to avoid to some meeting conflicts. -- SY, Jen Linkova aka Furry

Hi, On Tue, Nov 03, 2015 at 11:21:42AM +0900, Shane Kerr wrote:

tl;dr Don't so cautious. Removing the "experimental" tag from IPv6 won't ruin the RIPE meeting.

What Shane said. Short and long form :-) The world *will* end, obviously, but it won't be due to removing the experimental tag from the IPv6-only SSID. (Pointing out that even Apple is requiring their developers to handle IPv6 nowadays...) 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 Tue, 3 Nov 2015 09:32:21 +0100 you wrote:

On Tue, Nov 03, 2015 at 11:21:42AM +0900, Shane Kerr wrote:

...

tl;dr Don't so cautious. Removing the "experimental" tag from IPv6 won't ruin the RIPE meeting.

What Shane said. Short and long form :-)

The world *will* end, obviously, but it won't be due to removing the experimental tag from the IPv6-only SSID.

(Pointing out that even Apple is requiring their developers to handle IPv6 nowadays...)

There is something I don't understand about this discussion. The network at RIPE meetings currently provides a good network experience. The wifi works, there is IPv6 that works, and for those living in the past (which is essentially all of us, because only a small fraction of the internet is actually reachable over IPv6), there is also native IPv4. The surprising thing to me is that there is a request to the ops team at the meeting to provide broken IPv4 by default. I can understand the desire to have experimental networks at a meeting to test what works and what doesn't work. But why should such a broken network be default? There are many broken networks in the world. Wifi often doesn't work, in many places there is no 3G GSM. Do we want to replicate that as well at a RIPE meeting? And even if only a limited number of IPv4 addresses were available such that some form of NAT would be required, it would be weird to require the ops team to deploy one particular solution (NAT64) instead of letting the ops team figure out which is best way to provide a network at the RIPE meeting. (Can't wait for a request for Atlas to support NAT64, that's going to be interesting) Another interesting can of worms is how to do DNSSEC local valication on the context of NAT64.

In your letter dated Tue, 3 Nov 2015 11:58:07 +0100 you wrote:

...

(Can't wait for a request for Atlas to support NAT64, that's going to be interesting)

Request!

I'll pass the request onto MCB on your behalf noting that a quick measurement shows that no probe is actually behind a DNS64 resolver. So it may not get a very high priority.

On 03 Nov 2015, at 11:53, Philip Homburg <pch-ripeml@u-1.phicoh.com> wrote:

[...]

There is something I don't understand about this discussion.

The network at RIPE meetings currently provides a good network experience. The wifi works, there is IPv6 that works, and for those living in the past (which is essentially all of us, because only a small fraction of the internet is actually reachable over IPv6), there is also native IPv4. The surprising thing to me is that there is a request to the ops team at the meeting to provide broken IPv4 by default.

+1 — Thank you for this. The default network is not v4-only. It’s a dual stacked network. Not sure why we want to call it legacy. At the end of the day, the OS [RFC 6724] is going to prefer v6 connections anyway.

I can understand the desire to have experimental networks at a meeting to test what works and what doesn't work. But why should such a broken network be default? There are many broken networks in the world. Wifi often doesn't work, in many places there is no 3G GSM. Do we want to replicate that as well at a RIPE meeting?

And even if only a limited number of IPv4 addresses were available such that some form of NAT would be required, it would be weird to require the ops team to deploy one particular solution (NAT64) instead of letting the ops team figure out which is best way to provide a network at the RIPE meeting.

(Can't wait for a request for Atlas to support NAT64, that's going to be interesting)

Another interesting can of worms is how to do DNSSEC local valication on the context of NAT64.

Best, Vaibhav ===================================================== Vaibhav Bajpai Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com =====================================================

Hi, On Tue, Nov 03, 2015 at 02:45:12PM +0100, Jen Linkova wrote:

RIPE Atlas probe is a host. It should not care much if it's traffic is going via NAT64 box or not.

Actually detecting NAT64 and flagging as such, and being able to run tests on a group of NAT64-hidden probes might add value... 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

On Tue, Nov 03, 2015 at 11:21:42AM +0900, Shane Kerr wrote:

Marco,

My impression is that you are representing the RIPE NCC's (semi-)official stance on this subject, so even though I am addressing this to you my mail is really intended to be towards the company.

tl;dr Don't so cautious. Removing the "experimental" tag from IPv6 won't ruin the RIPE meeting.

Honestly, I think that the RIPE NCC is being way too cautious. The remedy in all cases is simply "pick this other SSID".

Really, it's that simple!

Even the most technically inept users are experienced with selecting alternate WiFi networks.

I suppose there may be users who really, REALLY want to debug their setup (perhaps they are tired of their corporate VPN not working over IPv6-only, or something like that). In that case, the RIPE NCC certainly has no responsibility to work with these people, unless the company wants to and has spare resources. (There will be RIPE participants who are willing to help, so such people might be able to fix their setups with assistance from enthusiastic experts.)

+1 here folks. I have to agree with Shane's sentiments here. The "fix" for any problems is so trivial I really don't think transitioning the IPV6 only SSID from experimental to fully published, part of the standard meeting literature and on site advertisements is a problem. Fair play to Marco and co for wanting to ensure absolute perfection (in as near as can be) with regards to the meeting network(s) but suffice to say, I trust the RIPE ops folks implicitly to run a good set of networks for all of us. I also trust them to be able to help any users with problems (on either network). See you all in Romania anyway. -- Mick O'Donovan | Network Engineer | BT Ireland | Website: http://www.btireland.net Looking Glass: http://lg.as2110.net Peering Record: http://as2110.peeringdb.com AS-SET Macro: AS-BTIRE | ASN: 2110

Hi list, so far I've tried to stay out of this thread and do this face to face in Bucharest, but well... As I've said and written before, the responsibility for the operation of the network is with the NCC technical team, and as such it should really be their call when to change what. And I really appreciate Marco being extra careful with his wording (even if it reads like it's been written by a lawyer:-) On the other hand, I think it is our (as a WG) job to keep nudging them towards what the eventual outcome should be (which is an IPv6 only WLAN with as much IPv4 as there is IPX, SNA, or UUCP...). Maybe we can come to some sort of outline on how to get there during the meeting? After that we can then argue about actual timing without getting lost in the fog of detail. 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/

Hi Marco,

At the moment the actual capacity of the NAT64 network is not known. This means we cannot offer any guarantees on throughput or the number of simultaneous connections supported.

I understand that the network will remain a 'secondary' network for now. Running a network for so many attendees without knowing what the limits are would not be a good idea.

Meanwhile, we will gather some basic information such as number of clients connected to the network. Some RIPE NCC staff might use this opportunity to run tests as well. We encourage the community to keep track of any issues reported and to document them together with possible solutions.

This bit disappoints me a bit. There have been multiple voices on this list that want to push this forward. Rather than gathering basic information and maybe running a few tests I think we need a bit more extensive information/measurements/etc. so that we can have a discussion about this topic based on real data. I understand that it won't be possible to have that data for Bucharest. I don't want to ask for the impossible :) But I would really appreciate it if the technical team could investigate the possibilities a bit further so that we can have a good discussion about this at a future RIPE meeting.

We will make sure that staff will be available to participate in the working group discussion on this topic and we hope to meet you all there.

See you there! And thanks for working on this! Cheers, Sander

Hi Benedikt,

Come on, Sander. The NCC ops folks (Razvan and his lot) aren't exactly having a paid vacation trip during a RIPE meeting; they usually look just as tired as everybody else on friday, so asking for an unpredictable extra workload isn't exactly fair.

My apologies, I have worded it badly. I meant to say that I expected a few more measurements at the meeting followed by more testing and looking into possibilities for future RIPE meetings at the office. I'm definitely not expecting the ops folks to do everything during the meeting. I know how busy they are! As I said: I don't want to ask for the impossible! Sorry that it sounded like that.

Rather than just telling the ops folks what to do or not I really suggest we help them get the data they need to do the next step, which is to convince as many people as possible to use the IPv6 network and then give any feedback they can come up with.

+1 Cheers! Sander

Hi Benedikt, On 07/11/15 14:29, Benedikt Stockebrand wrote:

Hi Sander, Marco, and list,

Sander Steffann <sander@steffann.nl> writes:

...

Hi Marco,

...

At the moment the actual capacity of the NAT64 network is not known. This means we cannot offer any guarantees on throughput or the number of simultaneous connections supported.

Marco, you still sound like a corporate lawyer:-)

...

...

Meanwhile, we will gather some basic information such as number of clients connected to the network. Some RIPE NCC staff might use this opportunity to run tests as well. We encourage the community to keep track of any issues reported and to document them together with possible solutions.

This bit disappoints me a bit. [...]

Come on, Sander. The NCC ops folks (Razvan and his lot) aren't exactly having a paid vacation trip during a RIPE meeting; they usually look just as tired as everybody else on friday, so asking for an unpredictable extra workload isn't exactly fair.

It's not like I wouldn't love to hear the announcement during the opening plenary that IPv4 is only available wired from a single switch located in the terminal room, but looks like we'll have a couple rounds of nagging to do.

What I'd like to see, and that's well in line with what Marco wrote, is that we see if we can make as many people as possible actually try the IPv6 network out. No longer calling it "experimental" really is an important step here; talking about this during the opening plenary is even more important.

Rather than just telling the ops folks what to do or not I really suggest we help them get the data they need to do the next step, which is to convince as many people as possible to use the IPv6 network and then give any feedback they can come up with.

Oh, and one more thing: We might ease things up for ops if we actually managed to point out during the opening plenary that people with IPv6 stickers on their badges are generally volunteering as experimental^Winofficial first level IPv6 support...

@Nick: Can we do something about getting maybe 3 minutes worth of time during the monday plenary for this, or could somebody from the regular staff do such a quick announcement for us?

We'll ask Hans Petter to add this to his introductory talk at the start of RIPE 71. Our suggestion is to post the intermission slide we're building for the v6-only network and Hans Petter can point to it, filling in the details. Cheers, Nick

Cheers,

Benedikt