Enno Rey wrote : That is, in all seriousness, regrettable. I live and work in California, too, not far away from Sacramento. My ISP brings IPv6 to my home, I have it on my phones and I hear that the companies of people I meet over lunch serve terabytes of data over IPv6 every single day. It seems California is a quite diverse place, in many regards...

It is indeed. I do not hear, but I happen to run the network for a multi-billion campus, and your resume just got a static route to null0 for the next 20 years. Congratulations. Michel.

Hi, I think it boils down to a) deploy IPv6 where it makes sense for you to do so. b) remove IPv4 where it makes sense for you to do so. What “makes sense” for different people, organisations, and communities will differ. Stratgies at say Facebook and TalkTalk differ wildly. Tim On 4 Oct 2019, at 07:55, Carlos Friaças via ipv6-wg <ipv6-wg@ripe.net<mailto:ipv6-wg@ripe.net>> wrote: Hi WG, We have to acknowledge "IPv6 zealots" are real. Disclaimer: i think i was part of that group some years ago. I guess i understood i wasn't in that group anymore when i tried to help fix IPv4 distribution policies, while hearing some others say: "Don't touch that, let it burn fast! IPv4 burning fast will be good for v6". I then realized usability and the end-users are what needs to be protected, not IP version X or IP version Z just by the sake of technology coolness. We also have to acknowledge "IPv4 zealots" are real. I don't think i'm going to enter that group anytime soon, though. IMHO, Mr.Py has a point about monopolies & torpedoes. But Mr.Rey's reference about IPv6 deployment rates also makes a good point! I believe markets change. In some countries there is more regulation than others. And people in key positions also change companies, which sometimes impact what their old and new companies actually do/decide. I also don't think the WG has failed. 3 years ago i went to a RIPE meeting (in Madrid) with a (a less technical) colleague. On Thursday he told me that _ONE_ application didn't work/connect. That application was well-know to be IPv4-only and disliking translation mechanisms, so after 5 minutes of debugging the conclusion was easy: he had been connected to the IPv6-only meeting network since Monday and everything worked seamlessly. Some years ago i also did a local test by removing the IPv4 address from my laptop to see if i could bear with a full day of work without it. I couldn't. After two hours i placed it back, but at the time i already had a list of "things to fix", with stuff which was only accessible by IPv4. If you have the time, i recommend you to do it. It's also a way of advancing IPv6 deployment, if you have the time/patience. Regards, Carlos On Fri, 4 Oct 2019, Enno Rey wrote: Michel, On Fri, Oct 04, 2019 at 03:23:55AM +0000, Michel Py wrote: Wolfgang Zenker wrote : ... the results of the RIPE NCC survey published today lists the scarcity of IPv4 addresses as one of the largest challenges facing the participants in the survey. The participants in the RIPE NCC survey are not representative of the market. Here in the USA we have ... an IPv6 deployment rate of > 50%, see https://twitter.com/Enno_Insinuator/status/1179974955502428161. We are in the end of 2019, I live and work in California, and my ISP does not offer IPv6. That is, in all seriousness, regrettable. I live and work in California, too, not far away from Sacramento. My ISP brings IPv6 to my home, I have it on my phones and I hear that the companies of people I meet over lunch serve terabytes of data over IPv6 every single day. It seems California is a quite diverse place, in many regards... Your ideas are technically flawed, that being said. And you are not taking it to the right place. Try the IETF. that was funny. I mean both sentences are heavily flawed but at least the second gave me a good laugh. cheers Enno

Hi, Thus wrote Bjoern Buerger (b.buerger@penguin.de):

...

a) deploy IPv6 where it makes sense for you to do so. a) deploy IPv6 everywhere. Otherwise you are not reaching

Am Fri, 04 Oct 2019 schrieb Tim Chown: the whole internet.

For a sufficient number of networks that is a feature, not a bug. Not every net aspires to be Internet :) regards, spz

On Fri, 4 Oct 2019, Michel Py wrote:

Hi Carlos,

...

Carlos Friaças wrote : We have to acknowledge "IPv6 zealots" are real. Disclaimer: i think i was part of that group some years ago.

Indeed, and so was I. WAS.

...

But Mr.Rey's reference about IPv6 deployment rates also makes a good point!

Nobody cares about deployment rates. What good does it do, if people don't use it ? This is more realistic : https://www.google.com/intl/en/ipv6/statistics.html During the week, we are below 25%.

So...? Things move slowly, but they are moving. IPv6 in terms of volume is still a long way behind IPv4.

...

We also have to acknowledge "IPv4 zealots" are real.

And they are the ones with the money. The lobbyists. The connections. The banana peels. The 75% market share. The IPv4 zealots have not always been there; they have been created as a reaction to the nonsense of the IPv6 zealots.

Admitting that "zealotism" is not a got thing might be a good 1st step.

IPv6 replacing IPv4 is a delusion.

Same can be said about the oil-driven economy, however...

3 months ago, I turned DECNET off on my network. It was actually not even an IT/network decision; customer decided they were done with a product, and we de-commissioned the tools with DECNET. Business decision. We run OS/2 Warp, MS-DOS, Windows 95, HPUX, Solaris, Windows 2000, and I probably forget some.

So, hardly any IPv6 there :-)

In 20 years, I will still need IPv4.

Sure, if IPv6 doesn't become dominant.

And I have enough IPv4 on my hands for the foreseeable future. I bought some recently, just in case.

The "foreseeable future" is also a bit uncertain :-) If a new project pops up that will need 10x the public address space you have... good luck. But yes, a thick wallet might solve it... Cheers, Carlos

I encourage the WG group to read this : https://www.internetgovernance.org/2019/02/20/report-on-ipv6-get-ready-for-a... And the full text : https://www.internetgovernance.org/wp-content/uploads/IPv6-Migration-Study-f... Serious work, paid by ICANN.

Michel.

Hi, On Sat, 5 Oct 2019, Michel Py wrote:

...

Carlos Friaças wrote : Admitting that "zealotism" is not a got thing might be a good 1st step.

I did not create the IPv4 zealots, I joined their ranks by economic necessity. I do not like it, but I need the IPv4 ecosystem for 20 more years and I am not going to let the IPv6 zealots destroy my business.

Can you let everyone know which ASN or ASNs do you run...? :-)

...

...

3 months ago, I turned DECNET off on my network. It was actually not even an IT/network decision; customer decided they were done with a product, and we de-commissioned the tools with DECNET. Business decision. We run OS/2 Warp, MS-DOS, Windows 95, HPUX, Solaris, Windows 2000, and I probably forget some.

...

So, hardly any IPv6 there :-)

100% IPv4 :-)

OK, so you meant *old* Solaris :-)))

...

If a new project pops up that will need 10x the public address space you have... good luck.

I already have several times more public space than I need. And, $20/IP is nothing in the cost of a new project.

Sure. And you are sitting in the 2nd largest economy in the world? (or the 1st? i lost track...). And what about everyone else, sitting in different continents, in developing regions, where $20/IP is really a show-stopper...? The Internet is supposed to be global, right? Carlos

Michel.

Olivier MJ Crépin-Leblond wrote : I don't mean to be criticising in any way, but running services on obsolete operating systems is a risk in itself, if the computer is connected to the Internet.

We are well-aware of the risks. None of the production computers have Internet access. Most of the time, there is no DNS either, the USB ports (if recent enough) are disabled, there usually is a mouse or trackball or lightpen but not always a keyboard. Somehow, that data will eventually end up somewhere on an Internet portal that customers can access, but there are complex processes in between.

Everything has a sell by date. All hardware becomes obsolete too.

We are painfully aware of that, too. And we have spares dating back to the 486 area. We machine or 3D print some parts. We replace surface-mount ICs if required. I'm trying to VM these, but they often require some proprietary hardware that can't even be VM'ed. Because everyone has asked, why don't I just e-waste these pieces of antique junk ? because they drive a multi-ton multi-million tool that will take a year to replace with a team of two dozen people. Just the man hours are several hundred thousand dollars or possibly over a million, not to mention the cost of the tool. And even if the new tool runs on newer hardware and OS that could support IV6, the proprietary app probably won't in the first place. Michel.

Hi Alexander, All, Github is now owned by Microsoft. Someone from Microsoft reading this? Maybe Veronika from Microsoft and the UK IPv6 Council? Cisco: just saw a post from Eric Vyncke. :-)) Maybe the WG can grow the list of gaps, so they can (possibly?) start to be addressed...? Regards, Carlos On Sat, 5 Oct 2019, Alexander Koeppe wrote:

...

Am 04.10.2019 um 08:56 schrieb Carlos Friaças via ipv6-wg <ipv6-wg@ripe.net>:

Some years ago i also did a local test by removing the IPv4 address from my laptop to see if i could bear with a full day of work without it. I couldn't. After two hours i placed it back, but at the time i already had a list of "things to fix", with stuff which was only accessible by IPv4. If you have the time, i recommend you to do it. It's also a way of advancing IPv6 deployment, if you have the time/patience.

Same thing I?ve also tried several weeks ago The problem comes when trying to fix issues outside your reach.

For example: try to access Github. Even Cisco Website. Try to login. The intermediate step of the Pingfed solution doing the SSO login is IPv4-only.

This is very frustrating. The biggest network vendor isn?t fully reachable via IPv6-only.

- Alex

This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you must not copy this message or attachment or disclose the contents to any other person. If you have received this transmission in error, please notify the sender immediately and delete the message and any attachment from your system. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not accept liability for any omissions or errors in this message which may arise as a result of E-Mail-transmission or for damages resulting from any unauthorized changes of the content of this message and any attachment thereto. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not guarantee that this message is free of viruses and does not accept liability for any damages caused by any virus transmitted therewith.

Click http://www.merckgroup.com/disclaimer to access the German, French, Spanish and Portuguese versions of this disclaimer.

Hi, Fine, i get it: It's not only Microsoft and Cisco. But this WG goes way beyond Eric and Veronika... so we might have someone who can actually help already in the WG, or we (collectively) need to find those who can make a difference. But, imho, such list of 'gaps' is very, very useful! Cheers, Carlos On Sun, 6 Oct 2019, Jens Link wrote:

Carlos Friaças via ipv6-wg <ipv6-wg@ripe.net> writes:

...

Hi Alexander, All,

Github is now owned by Microsoft. Someone from Microsoft reading this? Maybe Veronika from Microsoft and the UK IPv6 Council?

Cisco: just saw a post from Eric Vyncke. :-))

twitter, slack, amazon, stackexchange, redhat (registration does not work on v6 only), ....

And from my Linux from Scratch experiment, see my presentation at RIPE76[1], all or at least some hosts from these domains dont support v6;

astron.com github.com greenwoodsoftware.com infodrom.org linuxfromscratch.org mpfr.org sourceforge.net sourceware.org tukaani.org zlib.net

Jens [1] https://ripe76.ripe.net/wp-content/uploads/presentations/146-we_dont_need_ip... -- ---------------------------------------------------------------------------- | Delbrueckstr. 41 | 12051 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink@quux.de | --------------- | ----------------------------------------------------------------------------

Replying to the Subject question. . . The WG has done good work. RIPE-554 in particular I think is good work. This WG isn't a marketing organization. That's appropriate. One way to look at the problem is that IPv4 exhaustion is a problem of externalities: my network is growing, and it costs me more now because you don't support IPv6. As an economic problem, then, think about how to shift your costs to those who have only IPv4. IPv6 deployment in your network means cutting your NAT expense in half. More, as more sites deploy. IPv6 deployment in your network might mean you can sell some of your IPv4 addresses, a clever way I've seen to fund the transition. IPv6 deployment on your web site means improving your page load time, and therefore SEO, and therefore revenue. At NANOG I showed quotes that IPv6 increases revenue by 0.2%-7%.[1] The cost to deploy IPv6 is not high: it's mostly labor, and people who complain that there's no training are ignoring the hundreds of tutorials, books, articles, videos, and web sites available to them for free, not to mention the thousands of friendly engineers. To everyone who sees a high cost, I ask whether you know the value of NAT reduction and web site speed (and avoiding buying addresses, or selling addresses), in $LOCAL_CURRENCY, so you can evaluate every obstacle you might encounter. For instance, "Our web conferencing doesn't support IPv6, and it'll cost us $9,000 a year to change. But IPv6 will save us $30,000." The decision is easy. In another message on this thread I noted that small ISPs are squeezed between CPE and IPv4 purchases. They can't get CPE that supports IPv6, or that supports MAP or 464xlat, because they don't buy enough, so they have to pay to buy addresses. That's easily solved by collective action: 100 small ISPs can get the features they want (at a better discount) than one acting alone. In the mean time, this WG keeps having fascinating presentations, which I keep using when talking about IPv6 to enterprise IT departments. Keep it up. Lee [1] https://youtu.be/aTi4fia5s-k?t=4386

Lee Howard <lee@asgard.org> writes:

Replying to the Subject question. . .

The WG has done good work. RIPE-554 in particular I think is good work.

This WG isn't a marketing organization. That's appropriate.

I'm not normally part of this wg, I just got sucked in because a poster cited a bunch of unicast extensions project work out of context.

One way to look at the problem is that IPv4 exhaustion is a problem of externalities: my network is growing, and it costs me more now because you don't support IPv6. As an economic problem, then, think about how to shift your costs to those who have only IPv4.

IPv6 deployment in your network means cutting your NAT expense in half. More, as more sites deploy.

There's no fungable or measureable "NAT expense". NAT generally saves money. Look at the container market for one recent example.

IPv6 deployment in your network might mean you can sell some of your IPv4 addresses, a clever way I've seen to fund the transition.

That I agree with. But I see no sign anyone is actually doing that. It's saner to horde at the moment.

IPv6 deployment on your web site means improving your page load time, and therefore SEO, and therefore revenue. At NANOG I showed quotes that IPv6 increases revenue by 0.2%-7%.[1]

BS. Happy eyeballs costs time.

The cost to deploy IPv6 is not high: it's mostly labor, and people who

BS. It needs to be implemented first in a deployable state.

complain that there's no training are ignoring the hundreds of tutorials, books, articles, videos, and web sites available to them for free, not to mention the thousands of friendly engineers.

To everyone who sees a high cost, I ask whether you know the value of NAT reduction and web site speed (and avoiding buying addresses, or

I note that port exhaustion is a real thing on ipv4 networks today that more should measure. In one recent set of "coffee shop tests", I had an over 30% initial syn failure rate. I don't know why (we were also testing ecn) at the moment, but that was a shocking number. ipv4 dns with udp was already using up a lot of udp port space. with quic eating up a lot of udp more, I'm not happy. JUST deploying dns over IPv6 as I did saved tons of udp port space under nat. That was a win.

selling addresses), in $LOCAL_CURRENCY, so you can evaluate every obstacle you might encounter. For instance, "Our web conferencing doesn't support IPv6, and it'll cost us $9,000 a year to change. But IPv6 will save us $30,000." The decision is easy.

That last number is pure BS. It's not a single cost. It's that last dangling set of apps that can't be converted to ipv6 that's the infinite cost.

In another message on this thread I noted that small ISPs are squeezed between CPE and IPv4 purchases. They can't get CPE that supports IPv6, or that supports MAP or 464xlat, because they don't buy enough, so they have to pay to buy addresses.

They can't get cheap CPE that has those features. ALL that code runs great in openwrt. And ipv4 addresses are needed until ipv6 hits 100% deployment.

That's easily solved by collective action: 100 small ISPs can get the features they want (at a better discount) than one acting alone.

Great. Is there an ISP association trying to do that already?

In the mean time, this WG keeps having fascinating presentations, which I keep using when talking about IPv6 to enterprise IT departments. Keep it up.

On Sun, 6 Oct 2019, Wolfgang Zenker wrote:

Also for many years, we don't actually do it. And whoever it is that decides not to do it, is certainly part of the RIPE community. The only reason I can see is that at least that part of the RIPE community does not consider IPv6-only + NAT64 to be "production ready".

On Android/iOS I'd say it's production ready. On classic desktop OSes like MacOS, Windows and Linux it's not. The difference is the presence of widely available 464XLAT support. -- Mikael Abrahamsson email: swmike@swm.pp.se

If I can get *one* person in this working group to go down to their local coffee shop and make ipv6 work by whatever means necessary (and also fix their bufferbloat) - I'll consider my participation in this thread a success.

On Mon, Oct 7, 2019 at 9:16 AM Job Snijders <job@instituut.net> wrote:

Dear Dave,

On Mon, Oct 7, 2019 at 4:04 PM Dave Taht <dave.taht@gmail.com> wrote:

...

If I can get *one* person in this working group to go down to their local coffee shop and make ipv6 work by whatever means necessary (and also fix their bufferbloat) - I'll consider my participation in this thread a success.

That may be how you measure success yourself, however I measure differently: I consider your input in this thread insightful and valuable, regardless of the coffee shop's connectivity.

:blush: I have some feedback on a couple other things that have gone by on these threads that I guess you just encouraged me to write. You might regret encouraging me, but here's something that just poured out.

Influencing the connectivity of any public place (bar, coffee shop, or mall) who don't consider their internet access service their core business, can be really tricky. Any anecdotal data gleaned from that experience is just that, anecdotal.

Every journey begins with a single step. *enough* anecdotal experience (and a unified set of questions to ask) gathered this way turns into scientific evidence and a plan for making things better along this portion of the edge. It's less complicated to turn your local coffee shop owner on than it is to convince an enterprise. (besides, it's fun - I work 2 days a week out of coffee shops - and in my (our!) best interest to make the coffee shop's internet work as good as possible. For all I know the gig will turn into money - if only my patreon was about 10x higher (https://www.patreon.com/dtaht) I could stop working on "pets.com" stuff to stay alive - and try to work on more difficult issues more regularly) So like I said, it would be great if more folk fixed their local coffee shop and got first hand experience at low scale with the real issues remaining with ipv6 deployment. I've worked on a few "newer" ipv6 related technologies that might help speed deployment. as well as observed a few things about networks along the edge. Since I'm new around here, for those that don't know - I used to live in Nicaragua, where I first volunteered for the OLPC project. I fell in love with life down there, until my wifi failed in the rainy season due to bufferbloat (if anyone here wants more of that origin story for how cerowrt came to be, see: https://www.youtube.com/watch?v=Wksh2DPHCDI ). There was zero IPv6 deployed there along the edge when I was last there (and given the political situation, it's unlikely I'll go back soon). There was no local place to tunnel, either. The fiber along the highway between nicaragua and coasta rica had been cut years prior and nobody was moving to replace it. Still, from 2006- 2011 we went from adhoc wifi links going over the mountain to a cable and fiber deployment that sort of worked. The fiber deployment was *weird* single channel stuff, and the cable deployment typically was 5Mbit/1mbit when I was last there (2016). The ISPs cheaped out greatly on all the gear, all the gear was not rated for high temp and humidity and failed a lot, and I have pictures of what your typical electrical and network cabling look like down there that will make you shudder.... Anyway... Multiple small coffee shops and hotels down in SJDS have the most debloated internet possible - 'cause I talked folk into turning stuff on (between surfing excursions and boat drinks) they already had. Over the years I used that distance to test in the real world codel's (and BBR's) response to longer RTTs, and most recently sch_cake ( https://arxiv.org/pdf/1804.07617.pdf ) - (The other major place we test long RTTs is on the island of mauritus) Anyway, my mission #1 is to upgrade the middleboxes worldwide, to fix bufferbloat. While we're doing that it would pay to try and deploy newer stuff like ipv6, DNSSEC, mo' ipv4, observe what users outside the english speaking community are doing, and so on. Here's some traceroutes, please let me talk to them: http://blog.cerowrt.org/post/nicaragua/ All the classic ipv6 over ipv4 tunnelling technologies failed. I was able to get stuff over udp4 to be fairly reliable, but not to any standard anyone here is used to. Power often flickers 6+ times a day, and hitting reload on websites massively common - try to nail up a tcp or ssh connection and good luck for more than a few hours. This was kind of the advantage to trying to do ipv6 tunnels as my ssh connections would survive a blink. But who cares about ssh in a web world? Now, based on some of those experiences - I tended to regard reliable power distribution as a key starting point. Education - in spanish - the next one. How much ipv6 training is there in spanish? Getting ipv4 to work at all is a high demand item due to the tourist trade, and things like skype and whatsapp are the big tourist applications, whatsapp and yourube (due to the literacy problem) the big apps for locals. Cell rolled out *amazinging* in 2011-2016. Everybody - in a country of 1000GDP per head - managed to get a phone with internet on it and used the first applications they were handed. (email is *dead*). I have a funny photo of the local milkman with an ox-drawn cart, tapping away on his phone... Anyway.... I've worked on means to make routing native ipv6 over unnumbered interfaces far, far easier with the babel protocol, and worked on securing it and the RFCs for that are final. The *code* doesn't scale well but at least it works over wireless links better than anything else I know. I tend to regard the ipv6 prefix distribution problem over such a mess of RFC1918 as the biggest problem we have in networks such this. Even with tunnels it's very problematic, even static. DHCPv6-pd over relays? don't make me laugh. like this (In fact, I'd really like to be able somehow get more ipv4 prefixes out to the edge on such networks also. It doesn't make any sense to backhaul everything up to managua over tin cans and string if it were possible to bring up a whole town) Anyway, total aside...

Kind regards,

Job

-- Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740

Bob, not meaning to spoil the party but while we're at it, and out of genuine interest: can you give us an update on the status of IPv6 in the Non-EE part of BT Consumer? thanks Enno On Mon, Oct 07, 2019 at 04:27:00PM +0000, bob.sleigh@bt.com wrote:

Congratulations on your contribution to success Dave!

Regards

Bob

Sent from my local coffee shop - using my EE Mobile over native IPv6

-----Original Message----- From: ipv6-wg <ipv6-wg-bounces@ripe.net> On Behalf Of Dave Taht Sent: 07 October 2019 17:04 To: Bjoern Buerger <b.buerger@penguin.de> Cc: ipv6-wg@ripe.net IPv6 <ipv6-wg@ripe.net> Subject: Re: [ipv6-wg] Have we failed as IPv6 Working Group?

If I can get *one* person in this working group to go down to their local coffee shop and make ipv6 work by whatever means necessary (and also fix their bufferbloat) - I'll consider my participation in this thread a success.

-- Enno Rey Cell: +49 173 6745902 Twitter: @Enno_Insinuator

Am Mo., 7. Okt. 2019 um 18:04 Uhr schrieb Dave Taht <dave.taht@gmail.com>:

If I can get *one* person in this working group to go down to their local coffee shop and make ipv6 work by whatever means necessary (and

Please start by eating your own dog food and make future RIPE meetings IPv6 only. Best Martin

Hi, On Mon, Oct 07, 2019 at 08:05:18PM +0200, Bjoern Buerger wrote:

* Martin Schr?der (martin@oneiros.de) [191007 19:13]:

...

Am Mo., 7. Okt. 2019 um 18:04 Uhr schrieb Dave Taht <dave.taht@gmail.com>:

...

If I can get *one* person in this working group to go down to their local coffee shop and make ipv6 work by whatever means necessary (and

Please start by eating your own dog food and make future RIPE meetings IPv6 only.

+1

Bj?rn

we should definitely have a discussion about this in the 'open mic' slot in the wg in Rotterdam. Let's identify who to talk to, from the meetings' NOC and other circles within RIPE NCC, beforehand. cheers Enno -- Enno Rey theinternetprotocol.blog Twitter: @Enno_Insinuator

...

Wouldn't it make more sense to first move this mailing list to an actual ipv6-only environment?

Bold move, but yes - why not?

I'm assuming this is sarcasm -- unless we really want to isolate ourselves from the very people we should be reaching out to. Rob

On the other hand, switching the "default" meeting SSID to IPv6-only/NAT64 while still providing the dual stack network as a fallback, preferably combined with a helpdesk staffed by volunteers ready to analyze any problems that attendees might have, strikes me as a pretty good opportunity to raise awareness and to find problems where further work is needed.

From a host perspective, NAT64 directly on wifi is not attractive: it will require an address translation component in every host to deal with legacy applications that handle IPv4 literals.

NAT64 is also not attractive from a backward compatibility point of view: IPv4-only devices and hosts that are dual stack but lack the 464XLAT component will fail. Considering those issues, why does it make sense to subject attendees of a RIPE meeting to such a network? Anybody who wants to test can do that in the current setup. Why trick other people into connecting to a network that they are unlikely to encounter anywhere else?

* Philip Homburg <pch-ripeml@u-1.phicoh.com> [191008 20:47]:

...

On the other hand, switching the "default" meeting SSID to IPv6-only/NAT64 while still providing the dual stack network as a fallback, preferably combined with a helpdesk staffed by volunteers ready to analyze any problems that attendees might have, strikes me as a pretty good opportunity to raise awareness and to find problems where further work is needed.

...

From a host perspective, NAT64 directly on wifi is not attractive: it will require an address translation component in every host to deal with legacy applications that handle IPv4 literals.

As I have used the NAT64 network at the last couple of meetings without any problems, I don't think there are that many applications around that woukd be used from the meeting network. Switching to NAT64 might help to get an impression of how widespread this kind of problem really is.

NAT64 is also not attractive from a backward compatibility point of view: IPv4-only devices and hosts that are dual stack but lack the 464XLAT component will fail.

We are still talking about the default SSID at the RIPE meeting, right? I guess IPv4-only devices will be kind of rare as a client in that network, but of course that is only me guessing. As for dual-stack hosts: the NAT64 network comes with DNS64, so you will get a synthesised IPv6 address for IPv4-only targets and connect via that address. Maybe I misunderstood your point?

Considering those issues, why does it make sense to subject attendees of a RIPE meeting to such a network? Anybody who wants to test can do that in the current setup. Why trick other people into connecting to a network that they are unlikely to encounter anywhere else?

"Trick other people" is not the intention, of course this would have to be made public together with the SSID of the dual-stack network still running as a fallback, and whom to contact in case of problems. It makes sense because the people interested to test this have already done so to the point of seeing no problems for themself. But that group is biased, probably running their services at home like vpn gateways at dual stack or IPv6-only already and therefore they might simply not encounter problems that might otherwise still be common. As IPv4 scarcity is a reality now, public wifi installations might want to use NAT64 networks eventually. So it makes sense to find out what would break and should be fixed before this is deployed unto an unsuspecting public. A community of highly qualified networking experts appears to be the right group of people to have for a test audience. Wolfgang

Hi Philip,

In contrast NAT64 breaks existing systems in lots of subtle (and not so subtle) ways. We cannot use NAT64 if we expect IPv4-only devices.

I would expect such devices mostly in a home network (gaming consoles etc). On a business meeting network like RIPE the number of IPv4-only devices is negligible.

We cannot use DNS64 if we expect IPv4 literals or local DNSSEC validation.

I am sure the few of us who run local DNSSEC validation would love the opportunity to make it work. Finding IPv4 literals and fixing them is a feature :)

The 464XLAT component is complicated did cause signficant operational problems in the past.

The net result is that with dual stack and NAT64 we now have two options of providing IPv6+IPv4 on a network. This is confusing to everybody who is not a network engineer.

This _is_ a RIPE meeting...

Does dual stack require more IPv4 addresses? No, there are (of course multiple) ways to provide dual stack on wifi without consuming additional public IPv4 addresses. Plenty of ISPs provide consumers with dual stack wifi at home while maintaining an IPv6-only access network.

There is also more and more live deployment of IPv6-only with NAT64. I am honestly surprised by the back pressure in the RIPE community. If production networks can deploy this for millions of users, why should a small conference network with a huge number of network engineers be any problem? Cheers, Sander

Hi, On Wed, Oct 09, 2019 at 06:26:18PM +0200, Philip Homburg wrote:

...

I would expect such devices mostly in a home network (gaming consoles etc). On a business meeting network like RIPE the number of IPv4-only devices is negligible.

I'm confused how it can be a good thing to use a different way to connect to a RIPE meeting network then the one you would use at the office or at home.

Having "different network types" is, in itself, not a useful thing. But it's reality - you'll end up being in any sort of network when travelling. So exposing *network people* to the possible breakages of "oh, if I have no native IPv4 on wifi anymore, my multi-million VPN solution stops working" is a useful information. And much more useful than having your CEO call you at 3am from a wifi network in China with "I HAVE ONLY IPV6 HERE AND VPN IS NOT WORKING! GO FIX! NOW!". IPv6 does break things. They all need fixing. To *know* what is broken in the gazillion of different combinations of operating systems, vendors, applications needs exposure. Leaving comfort zone. [..]

I'm very happy with dual stack. It is a technology that just works and doesn't need fixes on the host. Network configuration on hosts is complicated enough. We don't need more options.

Dual-stack is a pile of shit. It requires dual the amount of monitoring to *ensure* both protocols are both working correctly, dual the amount of firewall rules, etc. Worse, things like HE hide breakage in one protocol, so you "assume" you have a working dual-stack network, "because nobody is complaining"... Core networks need to run dual-stack for a long time to go, and it is a pain in the behind. Dual monitoring, dual routing protocols, dual filtering, ... (unless you do tricks with "two AFIs over one session", but peers usually do not support that). Inside edge networks, single-stack is the only thing that really makes sense - either hide in an IPv4 island behind a dual-stack application gateway, or go IPv6-only with DNS64/NAT64 (and possibly 464xlat) or with an dual-stack ALG to reach those IPv4-only services out there. [..]

...

I am honestly surprised by the back pressure in the RIPE community. If production networks can deploy this for millions of users, why should a small conference network with a huge number of network engineers be any problem?

There is quite a lot of NAT64 in mobile networks. As far as I know there is very little NAT64 on wifi. But I might be wrong. Any pointers to wide scale NAT64 on wifi?

Troopers runs their main conference wifi with NAT64. If I'm not mistaken, so does FOSDEM. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer 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 Thu, 10 Oct 2019 23:56:12 +0200 you wrote:

* Gert Doering (gert@space.net) [191009 19:57]:

...

Troopers runs their main conference wifi with NAT64. If I'm not mistaken, so does FOSDEM.

True. FOSDEM was Dualstack till 2013 and then switched to IPv6-only in 2014.

FOSDEM is similar to the RIPE meeting in that they have both a dual stack SSID and a NAT64 SSID. The difference is that FOSDEM promotes the NAT64 SSID as the main one and the dual stack SSID as the fallback.

* Philip Homburg (pch-ripeml@u-1.phicoh.com) [191011 09:31]:

...

...

Troopers runs their main conference wifi with NAT64. If I'm not mistaken, so does FOSDEM.

True. FOSDEM was Dualstack till 2013 and then switched to IPv6-only in 2014.

FOSDEM is similar to the RIPE meeting in that they have both a dual stack SSID and a NAT64 SSID.

The difference is that FOSDEM promotes the NAT64 SSID as the main one and the dual stack SSID as the fallback.

Yes. Which is exactly what we ask for . Just switch the default and see what happens. https://blogs.cisco.com/developer/fosdem-2019-a-new-view-from-the-noc Bjørn

Hi, On Fri, Oct 11, 2019 at 01:46:16PM +0200, Philip Homburg wrote:

Maybe there is another question this working group can answer: Does this working group recommend wifi deployments as NAT64? (of course only NAT64, not paired with dual stack on another SSID) - Is it recommended for a coffee shop or restaurant - Is it recommended for an office lan, - for a home situation - for just a random conference?

Given that doing dual-stack anywhere is "dual work", my recommendation for anything that needs proper monitoring would be "go single-stack if all possible". Which nowadays for "random visitor networks" can mean "NAT64+DNS64", given that this already nicely works in mobile networks and more and more "mobile internet usage" stuff is "iOS/Android clients or all-https" anyway. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

Let me first start with an alternative suggestion, and then delve into Sander's message itself. At IETF meetings there are numerous experiments going on at any given time too. Popping up an SSID for each experiment is not ideal, ever changing SSID names, or having too many SSIDs is not productive. So... one of the ideas to be explored is that there is a only a *single* SSID, but through WPA-802.1X let the username decide what 'profile' you want. It could be set up in such a way that depending on whether folks type in username "ipv4" or "dual" or "ipv6", they get an IPv4-only, Dualstack, or IPv6-only experience. If this approach is considered all flavors of wifi are equal, perhaps pacifying all factions attending RIPE. Ok, back to bickering: On Wed, Oct 09, 2019 at 05:06:09PM +0200, Sander Steffann wrote:

I am sure the few of us who run local DNSSEC validation would love the opportunity to make it work. Finding IPv4 literals and fixing them is a feature :)

"DNSSEC to the host" might be the path forward as an alternative method to accomplish some of the desirable properties of DoH. If your goal is to find IPv4 literals, go ahead, find them. Perhaps other people have other priorities during the meeting and would like to focus on those instead. Perhaps, when I find an IPv4 literal, I can't fix it because it is outside my administrative domain. Then what?

...

The 464XLAT component is complicated did cause signficant operational problems in the past.

The net result is that with dual stack and NAT64 we now have two options of providing IPv6+IPv4 on a network. This is confusing to everybody who is not a network engineer.

This _is_ a RIPE meeting...

Thank you for the clarification, so we agree it is not the "IPv6 Only Meeting".

...

Does dual stack require more IPv4 addresses? No, there are (of course multiple) ways to provide dual stack on wifi without consuming additional public IPv4 addresses. Plenty of ISPs provide consumers with dual stack wifi at home while maintaining an IPv6-only access network.

There is also more and more live deployment of IPv6-only with NAT64. I am honestly surprised by the back pressure in the RIPE community. If production networks can deploy this for millions of users, why should a small conference network with a huge number of network engineers be any problem?

For instance, it interferes with having a proper debugging experience on what happens when RPKI Invalids are dropped for both address families. I personally think that routing security in general is more important than this ipv6 project. DNS folks might also have their own agenda. RIPE is more than IPv6. There ALREADY is an IPv6-only+NAT64 Wifi SSID. Use it if you want to. If there aren't enough users on it, go back to the drawing board and explore why that is. I maintain, let's first move this mailing list to an IPv6 only environment, if that is a success, perhaps we can reconsider. If the argument is "but then the rest of the world can't talk to us"... exactly. Kind regards, Job

Hi, On Thu, 10 Oct 2019, Jen Linkova wrote: (...)

...writing this email from IPv6-only WiFi...

Just out of plain curiosity: home environment, corporate environment, or something else (i.e. 3rd party-managed, like an airport, coffee-shop)? Cheers, Carlos

By the way: *single* SSID, What is the reason to provide "ripemtg" and "ripemtg-2.4-79"? Outside of Ripemeetings I don't see different IDs for the different wifi frequencies. e.g. the eduroam in Munich, with daily 50000 Users in peak, works fine without two separate SSIDs

Philip Homburg <pch-ripeml@u-1.phicoh.com> writes:

NAT64 is also not attractive from a backward compatibility point of view:

At the last meeting Enno talked[1] about plans for a large wireless deployment running v6 only + NAT64 / DNS64. As I know which "Supermarket" Enno is talking about: If this would be deployed in the next 6 month many participants of RIPE 80 would use such a network. Jens [1] https://ripe78.ripe.net/wp-content/uploads/presentations/117-RIPE78_ERNW_IPv... -- ---------------------------------------------------------------------------- | Delbrueckstr. 41 | 12051 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink@quux.de | --------------- | ----------------------------------------------------------------------------

In your letter dated Mon, 7 Oct 2019 19:12:37 +0200 you wrote:

Please start by eating your own dog food and make future RIPE meetings IPv6 only.

I'm curious, who's dog food is that? None of the networks I connect to using wifi is 'IPv6-only'. I would love to drop IPv4 support in the code I write, but reality will be that I will have to support IPv4 for a long time.

Dave Taht <dave.taht@gmail.com> writes: Dave,

If I can get *one* person in this working group to go down to their local coffee shop and make ipv6 work by whatever means necessary (and also fix their bufferbloat) - I'll consider my participation in this thread a success.

you have to be strong now. Your participation in this list is not a success. I know at least two places I'd count as coffee shop (besides coffee they also server real breakfast, lunch, dinner, cocktails, ...) who I don't need to convince to do IPv6. They just do it. I get a RFC1918 address and a global IPv6 address. And they don't mangle DNS, they don't have any strange portal where you have to accept an unknown usage policy. You just sit down, connect to the wireless and can work. One of those stores is just a couple of hundred meters from my current hotel so I consider it "local". And as they have around 90 franchise partners in Germany probably there are more then two offer 2 shops offering this service. Jens -- ---------------------------------------------------------------------------- | Delbrueckstr. 41 | 12051 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink@quux.de | --------------- | ----------------------------------------------------------------------------

No you didn’t, that’s too easy ;-) Any random cafe in Brussels will do ;-) --a

On 8 Oct 2019, at 13:21, Eric Vyncke (evyncke) via ipv6-wg <ipv6-wg@ripe.net> wrote:

At Brussels Midi station...

Did I win anything ? <image001.png> On 07/10/2019, 18:04, "ipv6-wg on behalf of Dave Taht" <ipv6-wg-bounces@ripe.net on behalf of dave.taht@gmail.com> wrote:

If I can get *one* person in this working group to go down to their local coffee shop and make ipv6 work by whatever means necessary (and also fix their bufferbloat) - I'll consider my participation in this thread a success.