You are here: Home > RIPE Forum > IPv6 Working Group > [ipv6-wg] Have we failed as IPv6 Working Group?
RIPE Forum v1.4.1

IPv6 Working Group

Collapse

[ipv6-wg] Have we failed as IPv6 Working Group?

Wolfgang Zenker

2019-10-03 21:41:17 CET

Hi,

the description of the working group says:
"The IPv6 Working Group is for anyone with an interest in the next
generation Internet Protocol. The activities of the WG include education
and outreach, sharing deployment experiences and discussing and fixing
operational issues."

I know we do all of this at RIPE Meetings and maybe other times as well,
but still ...

... the default network at RIPE Meetings is the dual-stack network, with
the IPv6-only (NAT64) network as a barely used extra which is "supported
on a best effort basis". With the effect that almost no-one except a few
"ipv6 zealots" uses it. This tells me that a significant part of the
RIPE community does not only consider this setup "not production ready"
but expects an amount of breakage so huge that it's not acceptable to
try it out and see what would actually break (while still offering a
dual-stack network as a fallback, of course).

... 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. At the same time, about one quarter of
participants has no plans for deploying IPv6, with the most common
reason given as "there is no business requirement for IPv6". This tells
me that a significant part of the RIPE community does not view a
migration to IPv6 as a useful way to deal with the shortage of available

These two examples both concern the RIPE community, a group of people
that are highly interested and knowledgeable in the field of internet
operations. Now think about what the situation might look like at your
friendly neighbourhood IT shop or network department.

I maybe wouldn't call the IPv6 WG "failed", but it clearly still has a
long way to go until we can claim "mission accomplished".

Wolfgang



Michel Py

2019-10-04 05:23:55 CET

> 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 a saying : "You can lead a horse to water, but you can't make it drink".
As well as in the ARIN region, the strategy of the IPv4ever camp has been for quite a few years that the IPv6 zealots are doing a better job to discredit themselves. People will get tired of the failed FUD. We don't do anything to torpedo IPv6, you are digging your own grave.

You have not failed as a working group. The failure was not yours.
As I once did, you have done your best to promote IPv6.
I did IPv6 20 years ago, and now I don't do it anymore.
I was on the 6bone. I taught IPv6 at the University of California 15 years ago.
I had my own ASN at home to multi-home with 2 tunnels. On aDSL.
And now I'm IPv4 only. Why ? it does not do any good to me.
None of my customers have it. None of my supply chain have it.

The failure is in the original design of IPv6, the FUD that has been going on for 20 years, and the lack of an actual problem to solve.
For the established ISPs, IPv4 scarcity is not a problem, it's a blessing. Besides other difficulties, IPv4 favors a monopoly of established players, who have been doing everything to keep it that way.

The failure of the IPv6 design was that it did not understand market forces nor money incentives.
IPv6 cannot succeed when more than half of the big players actively torpedo it to preserve their monopolies.

> "there is no business requirement for IPv6".

There is none for me or my company. Dual-stack is a nightmare that I don't have the resources to implement.
Why should I bring it to the C-level, while I do not see any ROI for 10 years ?

The RIRs and the ISPs do not decide for the market. Large ISPs may influence which protocol they force-feed to their residential suppliers, but not to the enterprise.

> This tells me that a significant part of the RIPE community does not view a migration
> to IPv6 as a useful way to deal with the shortage of available IPv4 address space.

For one good reason : they understand that NAT466464 requires as much logging as plain old NAT444, so why bother ?

> I maybe wouldn't call the IPv6 WG "failed"

You have done good, but the deck was not stacked into your favor.
If you are smart, you will understand that IPv6 is not going to replace IPv4 in the next 20 years.
We are in the end of 2019, I live and work in California, and my ISP does not offer IPv6.
Why ? because nobody asks for it.

In the ARIN region, we ran out of IP addresses in 2015, 4 years ago than you guys are about to get to.
The Internet has not stopped. In 4 years, in the RIPE region, after you run out, it will still be up, too.

Oh, and now some troll food :

> after now almost 12 years using, working and teaching IPv6 I've
> come to the conclusion that IPv6 is a mistake and will not work.

I'm afraid that I have to agree with this.

Your ideas are technically flawed, that being said. And you are not taking it to the right place.
Try the IETF.

Michel.



Enno Rey

2019-10-04 06:41:22 CET

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



Michel Py

2019-10-04 07:02:08 CET

> 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.



Carlos Friacas

2019-10-04 08:55:47 CET

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
>
>



Tim Chown

2019-10-04 11:03:52 CET

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 _at_ ripe _dot_ netipv6-wg _at_ ripe _dot_ 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



Bjoern Buerger

2019-10-04 15:53:24 CET

Tim,

Thanks for your thoughts. But I think you just
got that slightly wrong:

Am Fri, 04 Oct 2019 schrieb Tim Chown:
> 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.

Let me correct that for you:

a) deploy IPv6 everywhere. Otherwise you are not reaching
the whole internet. There are networks out there, which
you are currently missing. If you think otherwise, drop
me a note at bbu _at_ penguin _dot_ de

b) Hide all your legacy cruft behind some layers of NAT
or Dualstack Application Proxies, if it please you and
remove IPv4 where it makes sense for you to do so.

Cheers,
Bjørn



Michel Py

2019-10-04 18:16:19 CET

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%.

> 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.
IPv6 replacing IPv4 is a delusion.

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.

In 20 years, I will still need IPv4.
And I have enough IPv4 on my hands for the foreseeable future. I bought some recently, just in case.

I encourage the WG group to read this :
And the full text :
Serious work, paid by ICANN.

Michel.



Dave Taht

2019-10-04 22:55:30 CET

Michel Py <michel _at_ arneill-py.sacramento.ca _dot_ us> writes:

> 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.

As was I. Straws that broke my back finally were not being able to get a
static IPv6 address out of comcast, my hurricane tunnel getting blocked
by netflix, the still-huge prefix sub-distribution problem. The idea of
dynamic 2 week prefixes in part of the world prone to earthquakes
doesn't work for me... and my email over ipv6 is perpetually getting
blocked. spamhaus blocked multiple attempts to get dave _at_ taht _dot_ net
(fully ipv6 enabled) to
send mail ti this list. And I sat on it for an hour after clearing it,
in the hope the block would clear. It didn't. Getting off email
blocklists isn't
a problem users can handle... and spamhaus has no means of interacting with me.

I *really* wanted email right to my servers in my office to just work, over
ipv6.

Everywhere I've been lately (nicaragua, portugal) has switched
to whatsapp.

Damn it, I wanted ipv6 to roll out faster than it has.

I'm in a half dozen RFCs, worked in IETF homenet, founded the cerowrt
project with an explicit goal of making ipv6 more deployable (as we
did!), *by actually implementing and distributing* more code based on
the standards, and I plan to keep working on making ipv6 better, but
that said, we need more running code, still, which only then can
get into a deployment, and nobody's funding that.

Nobody's implemented much of ietf homenet. there's no code to enable prefix
distribution on android. those are my top two ipv6 bullet items. more
universal SADR would help. Tunnels of all types "just working" would
be good too.

Perhaps with the chinese government mandating more ipv6, more open
source code, at least, will get funded and written. Maybe not of the
freedom and privacy enhancing stuff, though.

>
>
>> 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%.

One entertaining thing I've been up to is checking the state of multiple
kinds of deployment in the coffee shops of the world with a string
of simple tests anyone can do (after we package them up better)

https://lists.bufferbloat.net/pipermail/bloat/2019-September/009334.html

So far thats:

Bufferbloat: 95% (starbucks is doing the right thing here, yea!)
IPv6: 0%
DNSSEC: 0%.

"coffee shop testing"

offers y'all the opportunity to go "fix it" by leaping over the
counter, and/or to get a deeper grip on the real deployment problems we
have with middleboxes along the edge. Sometimes leads to free coffee,
too! Please have more meetings in coffee shops, not conventions!

Does anybody here, know what the heck the 5G people plan to do with
IPv6? and new places like starlink and oneweb and the like?

I really hope the 5G folk are going to get ipv6 prefix distribution and
SADR right, but have no data.

>
>> 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.
> IPv6 replacing IPv4 is a delusion.

I should make clear I'm not a zealot of any sort on the ipv4 vs ipv6
front. (I freely confess to being zealous about fq_codel... but if you
deployed it and looked at the data, I figure more would become one also! :))

I came to the reluctant conclusion last year that dual stack is going
to be ~forever,
that ipv6 was platauing in multiple ways and we needed to kick it harder, that
the rollout stats vs actual usage were hopelessly overoptimistic...
and went poking at what we
could do to ALSO make ipv4 better as a third way out and have been
plunking away it ever since. One thought was:

Since there was demand for more IPv4, perhaps that would also fuel

As for money to make middleboxes better in *any* way, don't make me
laugh. During the cerowrt project we approached everybody making money
from the internet and multiple non-profits and got nowhere. I spent
my own fortune on it, and got a lot of volunteers onboard, especially
in the openwrt universe... and made things better, but I got nothing left.

We need a new kame-like project to jointly handle the cracks in the
ipv6 network architecture, standards and code, at the very least.

The costs of "mo ipv4" are trivial in comparison.

> 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.

Please note the ipv4 extensions stuff won't work with most that
"legacy" ipv4 stuff.
It can, however, enable new applications and services to exist. Most of
the IOT and SDN stacks already do work. Most don't have decent ipv6 support
due to resource constraints.

Perversely I kind of like the idea of a portion of the internet immune from
legacy windows worms and viruses....

>
> In 20 years, I will still need IPv4.

And it seems possible we can make more.

> And I have enough IPv4 on my hands for the foreseeable future. I bought some recently, just in case.
>
>
> I encourage the WG group to read this :
> And the full text :
> Serious work, paid by ICANN.

We cited that work in our presos on this subject as that was also key
on gilmore, paul wouters and myself to start looking hard at what it
would take to make ipv4 better in multiple ways. Please look it over!?

The ipv4 unicast extensions project is one outgrowth of that: A string
of trivial patches to a couple OSes and routing daemons and we're well
on our way to being able to add 420m new addresses to the internet,
within a 10 year time horizon.

Politically... oh, lawd. I'm focusing on technical feasibility only at the
moment. If you want some details about that, see the WIP here:

https://github.com/dtaht/unicast-extensions/tree/master/rfcs

I'd like lots more folk to review this before we punt it up to iana
and the ietf,
the RIRs and so on, and more to fiddle with 240/4 and 0/8, at least. Pay
special attention to section 7.1.

There's more than just this to make ipv4 better, possible. Taking
flack on just this much is no fun, but can we get more folk
thinking out of this box in general?

We certainly aren't proposing that ipv6 wg's *disband* but if more
folk would focus on making the code work and implementing more
of the standards that exist, AND looking at deployment problems
with an open mind and willingness to get in there and fix them,
that would be a goodness.

--

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



Michel Py

2019-10-05 00:51:40 CET

> Dave Taht wrote :
> https://github.com/dtaht/unicast-extensions/tree/master/rfcs
> I'd like lots more folk to review this before we punt it up to iana and the ietf,

IMHO, 240/4 is worth the effort as an extension to RFC1918 but the rest of that (127/8, 0/8) is not worth the effort. One or two more class A blocks does not change the big picture.

And I suppose you are aware that there were several attempts before, including the last one submitted by APNIC, and that they all have been torpedoed by the IPv6 zealots.

Michel.



2019-10-05 03:46:55 CET

Hi Wolfgang,

On Fri, Oct 4, 2019 at 5:41 AM Wolfgang Zenker <zenker _at_ punkt _dot_ de> wrote:
> ... the default network at RIPE Meetings is the dual-stack network, with
> the IPv6-only (NAT64) network as a barely used extra which is "supported
> on a best effort basis". With the effect that almost no-one except a few
> "ipv6 zealots" uses it. This tells me that a significant part of the
> RIPE community does not only consider this setup "not production ready"
> but expects an amount of breakage so huge that it's not acceptable to
> try it out and see what would actually break (while still offering a
> dual-stack network as a fallback, of course).

I'm not sure I can follow the logic here. What you are saying about
'do not consider production ready' would have been true if users made
a decision which SSID to connect every time (and that decision took
into account the protocol version). But it's clearly not the case.
First time attendees connect to whatever SSID is specified in the
booklet and/or has the most intuitive name. Returning attendees let
their laptops/phones connect to SSID their devices remember.

There is an SSID which has been there for years, which is printed on
the booklets etc and it's name matches the meeting name.
And there are other SSIDs - which are not listed in the booklet, their
names are longer (which for MacOS at least might mean that they are
shown *below* the main one in the list) etc. I'm sure that even if all
of them were dual-stack, the main one would have attracted the vast
majority of the userbase.

> ... 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. At the same time, about one quarter of
> participants has no plans for deploying IPv6, with the most common
> reason given as "there is no business requirement for IPv6".

The survey says: "Over half of respondents indicated that they will
need more IPv4 address space in the short term."
I read it as '~50% of respondents do not need IPv4 in the short term".
And only 1/4 do not see the business requirements for IPv6".  Twice
less that I'd have expected then..

Another quote: "A further 44% of respondents who indicate they will
not need more IPv4 stated that their organisation has/will have
deployed IPv6. "
I'd not call it a failure.

>This tells me that a significant part of the RIPE community does not view a
> migration to IPv6 as a useful way to deal with the shortage of available

Yet.

> I maybe wouldn't call the IPv6 WG "failed", but it clearly still has a
> long way to go until we can claim "mission accomplished".

I do  not think anyone promised it's going to be easy ;)

On a more serious note, two things:
1) I quickly checked the 2013 survey. It does not even mention IPv6.
Are you still calling it 'no progress' and 'failure'? ;)
2) By lucky coincidence we have  a slot in Rotterdam to discuss the
working group strategy and future. Let's talk about it.

--



S.P.Zeidler

2019-10-05 10:51:16 CET

Hi,

Thus wrote Bjoern Buerger (b.buerger _at_ penguin _dot_ de):

> Am Fri, 04 Oct 2019 schrieb Tim Chown:
> > a) deploy IPv6 where it makes sense for you to do so.
> a) deploy IPv6 everywhere. Otherwise you are not reaching
>    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



Nick Hilliard

2019-10-05 13:33:49 CET

Michel Py wrote on 04/10/2019 23:51:
> And I suppose you are aware that there were several attempts before,
> including the last one submitted by APNIC, and that they all have
> been torpedoed by the IPv6 zealots.

The cost of making 240/4 usable is to update every device on the planet,
including legacy ipv4 stacks.

240/4 is 16x/8.  Before ARIN reached exhaustion, this would have
constituted a little more than 1 year of RIR consumption.  Bringing
240/4 into production won't change the principle that ipv4 address
exhaustion is going to happen: the only thing it does is to move the
date a couple of months down the road.

There are plenty of people who are not ipv6 zealots, but who view this
this as not worth it.  Nothing fundamental is going to change, and the
cost is very high.

Nick



Lee Howard

2019-10-05 15:05:39 CET

On 10/4/19 4:55 PM, Dave Taht wrote:
> not being able to get a
> static IPv6 address out of comcast, my hurricane tunnel getting blocked
> by netflix, the still-huge prefix sub-distribution problem. The idea of
> dynamic 2 week prefixes in part of the world prone to earthquakes
> doesn't work for me...

I can think of several programmatic ways to deal with that. Or you can

> that said, we need more running code, still, which only then can
> get into a deployment, and nobody's funding that.

Do you mean CeroWRT specifically, or code in general?

I was thinking about some Hackathon projects to add IPv6 capability to
open source projects. Seems to me the hardest part is making sure

>>> 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%.

APNIC's statistics show that in almost every network that has IPv6, it
is almost always used.

> One entertaining thing I've been up to is checking the state of multiple
> kinds of deployment in the coffee shops of the world with a string
> of simple tests anyone can do (after we package them up better)

Yeah, we need the GoGo and ATTWifi and such of the world to deploy.

> Since there was demand for more IPv4, perhaps that would also fuel
> more updates to ipv6, as
>
> As for money to make middleboxes better in *any* way, don't make me
> laugh. During the cerowrt project we approached everybody making money
> from the internet and multiple non-profits and got nowhere. I spent
> my own fortune on it, and got a lot of volunteers onboard, especially
> in the openwrt universe... and made things better, but I got nothing left.
>
> We need a new kame-like project to jointly handle the cracks in the
> ipv6 network architecture, standards and code, at the very least.
>
> The costs of "mo ipv4" are trivial in comparison.

One of the reasons small ISPs can't deploy IPv6 is that they don't
control the features in the CPE, because they don't buy enough.

I know a couple CPE vendors who would be happy to provide a specific
feature set for a guaranteed purchase of a couple thousand units a
month. This sounds like a good business to me: if a bunch of small ISPs
each contract for a specific number of units, but require RIPE-554,
RFC7084, and RFC8085, we could both get the needed features, and get a
larger volume discount than they get now.

Saving $1 per CPE is better than spending$20 for an IPv4 address for
every new user. Please confirm my math. :)

>
>> 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.
> Please note the ipv4 extensions stuff won't work with most that
> "legacy" ipv4 stuff.
> It can, however, enable new applications and services to exist. Most of
> the IOT and SDN stacks already do work. Most don't have decent ipv6 support
> due to resource constraints.
>
> Perversely I kind of like the idea of a portion of the internet immune from
> legacy windows worms and viruses....

DECNET isn't on the Internet. I don't care if some crusty old boxes in
dark corners of data centers whisper IPv4 among themselves. How would I
even know?

>
>> In 20 years, I will still need IPv4.
> And it seems possible we can make more.
>
>> And I have enough IPv4 on my hands for the foreseeable future. I bought some recently, just in case.
>>
>>
>> I encourage the WG group to read this :
>> And the full text :
>> Serious work, paid by ICANN.
> We cited that work in our presos on this subject as that was also key
> on gilmore, paul wouters and myself to start looking hard at what it
> would take to make ipv4 better in multiple ways. Please look it over!?
>
> The ipv4 unicast extensions project is one outgrowth of that: A string
> of trivial patches to a couple OSes and routing daemons and we're well
> on our way to being able to add 420m new addresses to the internet,
> within a 10 year time horizon.

HPUX, Solaris, Windows 2000," and now you say it's easy to upgrade.

Lee



Lee Howard

2019-10-05 15:27:55 CET

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.

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
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  Sander Steffann 2019-10-05 18:11:18 CET Hi, > 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. "We only do settlement-free peering on IPv6" ? Cheers, Sander  Michel Py 2019-10-05 18:13:48 CET > Nick Hilliard wrote : > The cost of making 240/4 usable is to update every device on the planet, > including legacy ipv4 stacks. No it is not. It costs nothing to the Internet, it only costs to those who chose to use it as private address space. More FUD. Michel.  Dave Taht 2019-10-05 18:17:45 CET Ironically enough, I waited 24 hrs for the spamhaus block to clear on my ipv6 addr for my main email account, it still hasn't. >Lee Howard <lee _at_ asgard _dot_ org> writes: > On 10/4/19 4:55 PM, Dave Taht wrote: >> not being able to get a >> static IPv6 address out of comcast, my hurricane tunnel getting blocked >> by netflix, the still-huge prefix sub-distribution problem. The idea of >> dynamic 2 week prefixes in part of the world prone to earthquakes >> doesn't work for me... > > I can think of several programmatic ways to deal with that. Yeah, in the case of my 10 year + running hurricane tunnel and services running on it, I could have just blackholed netflix's ipv6 addresses. Ask your typical user to do that. In the end I pulled it down and tried to leverage the dynamic ipv6 allocation I get only to give up on that for a variety of reasons. As for the 2 week expiry time - hate it. Anyone that lived through the 1989 quake here and tried to keep a network even sort of running would hate it too. for real use a static ipv6/48 to distribute is needed. Dynamic ipv6 assignments are fine if you are doing trivial stuff but if ipv6 is ever to even start to supplant ipv4 it's got to become more static. > Or you can > just buy Comcast's business service, which I think includes one IPv4 > address. I have comcast business service. I still couldn't last I checked, buy a static IPv6 network from them. > > > >> that said, we need more running code, still, which only then can >> get into a deployment, and nobody's funding that. > > Do you mean CeroWRT specifically, or code in general? Well, I was referencing the cerowrt project, which ran for 3 years, fixed about 120 bugs related to ipv6, and helped make openwrt entirely compatible with most ipv6 capable ISPs on the planet. And even with that there were a plethora of problems like too many RA's causing the firewall to reload too often that got fixed in cerowrt but not quite in openwrt, and lots I'm still pretty scarred from that effort. I remember losing hair to so many things. Stuff still dangling - 8 years later - are ipv6 reverse dns and prefix distribution more than one hop into the network. HOMENET's stuff is still too unstable to use and in a couple ways still inadaquate, even in theory. > I was thinking about some Hackathon projects to add IPv6 capability to > open source projects. Seems to me the hardest part is making sure > there's an adequate test environment. Hackathons ARE useful tools for getting a short burst of focused work out of people sharing the same space and time, but too many are thinking hackathons alone will solve more detailed design, coding and iteration problems; it's one of those ideas trivializing the costs of "Real Programming(tm)" that really bugs me nowadays. I could share here the detailed project management stuff that went into cerowrt's run (3 years), or the outline of work we did for make-wifi-fast - which we've now been at for over 5 years now - 3+ to get fq_codel to work right on wifi, 2 to rework the API to work for more devices, and a pointer to the latest work which has been going for 3+ months now - and for all that we've only accomplished about 1/10th what we wanted to do, and only on 4 chipsets (most recently intel's ax200 chips) out of the hundreds. Certainly testing is one of the hardest parts, also. > > >>>> 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%. > > (Replying to an item upthread) > > APNIC's statistics show that in almost every network that has IPv6, it > is almost always used. I pointed to coffee shops as one counter example. To the lack of DHCPv6-PD on android (and I think, IOS) for tethering as another. > >> One entertaining thing I've been up to is checking the state of multiple >> kinds of deployment in the coffee shops of the world with a string >> of simple tests anyone can do (after we package them up better) > > Yeah, we need the GoGo and ATTWifi and such of the world to deploy. I'm more concerned at the moment that the 5G people aren't planning to do ipv6 right at all, and have no idea what the starlinks of the world, plan. > > >> Since there was demand for more IPv4, perhaps that would also fuel >> more updates to ipv6, as >> both require middlebox updates... >> >> As for money to make middleboxes better in *any* way, don't make me >> laugh. During the cerowrt project we approached everybody making money >> from the internet and multiple non-profits and got nowhere. I spent >> my own fortune on it, and got a lot of volunteers onboard, especially >> in the openwrt universe... and made things better, but I got nothing left. >> >> We need a new kame-like project to jointly handle the cracks in the >> ipv6 network architecture, standards and code, at the very least. >> >> The costs of "mo ipv4" are trivial in comparison. > > Another thought I've had: > > One of the reasons small ISPs can't deploy IPv6 is that they don't > control the features in the CPE, because they don't buy enough. > > I know a couple CPE vendors who would be happy to provide a specific > feature set for a guaranteed purchase of a couple thousand units a > month. This sounds like a good business to me: if a bunch of small > ISPs each contract for a specific number of units, but require > RIPE-554, RFC7084, and RFC8085, we could both get the needed features, > and get a larger volume discount than they get now. Yes, the smaller ISPs should join together in a buying club like that. Tried to get that going in NZ once. Failed. tried harder to make the aftermarket do the right thing - the eeros and google wifi's of the world are doing ok, the bottom part of the market just copy/pastes whatever's in openwrt at that moment, slaps a label on it and ships it. So we focused on making the openwrt base as good as possible. > Saving$1 per CPE is better than spending $20 for an IPv4 address for > every new user. Please confirm my math. :) I always thought that ISPs would invest in their CPE far more than they have. Free.fr being a shining example! ISPs get paid for modem rentals and have customer support costs that could be reduced - that should have been a great ongoing funding source and motivation, alone. but I know a few vendors, like evenroute, doing bufferbloat AND ipv6 right, that have totally failed to crack ISP market thus far. and for no reason I can think of, the rental folk don't push out new hardware OR new software to their users - I think charter made an effort to get docsis 3.1 stuff out there and retire all the docsis 2.0 gear in place, but not comcast. Secondly none of those ipv6 standards help when you still really need a real IPv4 address, so yer still out the$20, IF you can buy the /24s you
need. And there's more ipv6 RFCs left without running, integrated code,
to support them.

>
>
>>
>>> 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.
>> Please note the ipv4 extensions stuff won't work with most that
>> "legacy" ipv4 stuff.
>> It can, however, enable new applications and services to exist. Most of
>> the IOT and SDN stacks already do work. Most don't have decent ipv6 support
>> due to resource constraints.
>>
>> Perversely I kind of like the idea of a portion of the internet immune from
>> legacy windows worms and viruses....
>
> DECNET isn't on the Internet. I don't care if some crusty old boxes in
> dark corners of data centers whisper IPv4 among themselves. How would
> I even know?
>
>
>>
>>> In 20 years, I will still need IPv4.
>> And it seems possible we can make more.
>>
>>> And I have enough IPv4 on my hands for the foreseeable future. I bought some recently, just in case.
>>>
>>>
>>> I encourage the WG group to read this :
>>> And the full text :
>>> Serious work, paid by ICANN.
>> We cited that work in our presos on this subject as that was also key
>> on gilmore, paul wouters and myself to start looking hard at what it
>> would take to make ipv4 better in multiple ways. Please look it over!?
>>
>> The ipv4 unicast extensions project is one outgrowth of that: A string
>> of trivial patches to a couple OSes and routing daemons and we're well
>> on our way to being able to add 420m new addresses to the internet,
>> within a 10 year time horizon.
>
> HPUX, Solaris, Windows 2000," and now you say it's easy to upgrade.

I didn't say it was "easy to upgrade" in the context of this legacy
gear, I said it was easy to "add" 420m addresses. 240/4 is almost fully
enabled in every OS except windows, for example. Fixed the last bug
in it for linux and openwrt last december. Deploying. 0/8 now.

Yea, people keep missing on this point. IPv6 is not globally reachable
either. To try and clarify: A new IOT device trying to backhaul its
data to 240.0.0.1 doesn't need to have a windows OS also trying to get to
that same address. Is that clearer? A new application can try to use

backtomymac runs over private ipv6 addrs, doesn't need to be accessible
to anything else.

Etc. Universal connectivity is dead as a dodo, regardless.

On Sat, Oct 5, 2019 at 6:06 AM Lee Howard <lee _at_ asgard _dot_ org> wrote:
>
>
> On 10/4/19 4:55 PM, Dave Taht wrote:
> > not being able to get a
> > static IPv6 address out of comcast, my hurricane tunnel getting blocked
> > by netflix, the still-huge prefix sub-distribution problem. The idea of
> > dynamic 2 week prefixes in part of the world prone to earthquakes
> > doesn't work for me...
>
> I can think of several programmatic ways to deal with that. Or you can
> just buy Comcast's business service, which I think includes one IPv4
>
>
>
> > that said, we need more running code, still, which only then can
> > get into a deployment, and nobody's funding that.
>
> Do you mean CeroWRT specifically, or code in general?
>
> I was thinking about some Hackathon projects to add IPv6 capability to
> open source projects. Seems to me the hardest part is making sure
> there's an adequate test environment.
>
>
>
> >>> 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%.
>
>
> APNIC's statistics show that in almost every network that has IPv6, it
> is almost always used.
>
>
> > One entertaining thing I've been up to is checking the state of multiple
> > kinds of deployment in the coffee shops of the world with a string
> > of simple tests anyone can do (after we package them up better)
>
> Yeah, we need the GoGo and ATTWifi and such of the world to deploy.
>
>
> > Since there was demand for more IPv4, perhaps that would also fuel
> > more updates to ipv6, as
> > both require middlebox updates...
> >
> > As for money to make middleboxes better in *any* way, don't make me
> > laugh. During the cerowrt project we approached everybody making money
> > from the internet and multiple non-profits and got nowhere. I spent
> > my own fortune on it, and got a lot of volunteers onboard, especially
> > in the openwrt universe... and made things better, but I got nothing left.
> >
> > We need a new kame-like project to jointly handle the cracks in the
> > ipv6 network architecture, standards and code, at the very least.
> >
> > The costs of "mo ipv4" are trivial in comparison.
>
>
> One of the reasons small ISPs can't deploy IPv6 is that they don't
> control the features in the CPE, because they don't buy enough.
>
> I know a couple CPE vendors who would be happy to provide a specific
> feature set for a guaranteed purchase of a couple thousand units a
> month. This sounds like a good business to me: if a bunch of small ISPs
> each contract for a specific number of units, but require RIPE-554,
> RFC7084, and RFC8085, we could both get the needed features, and get a
> larger volume discount than they get now.
>
> Saving $1 per CPE is better than spending$20 for an IPv4 address for
> every new user. Please confirm my math. :)
>
>
> >
> >> 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.
> > Please note the ipv4 extensions stuff won't work with most that
> > "legacy" ipv4 stuff.
> > It can, however, enable new applications and services to exist. Most of
> > the IOT and SDN stacks already do work. Most don't have decent ipv6 support
> > due to resource constraints.
> >
> > Perversely I kind of like the idea of a portion of the internet immune from
> > legacy windows worms and viruses....
>
> DECNET isn't on the Internet. I don't care if some crusty old boxes in
> dark corners of data centers whisper IPv4 among themselves. How would I
> even know?
>
>
> >
> >> In 20 years, I will still need IPv4.
> > And it seems possible we can make more.
> >
> >> And I have enough IPv4 on my hands for the foreseeable future. I bought some recently, just in case.
> >>
> >>
> >> I encourage the WG group to read this :
> >> And the full text :
> >> Serious work, paid by ICANN.
> > We cited that work in our presos on this subject as that was also key
> > on gilmore, paul wouters and myself to start looking hard at what it
> > would take to make ipv4 better in multiple ways. Please look it over!?
> >
> > The ipv4 unicast extensions project is one outgrowth of that: A string
> > of trivial patches to a couple OSes and routing daemons and we're well
> > on our way to being able to add 420m new addresses to the internet,
> > within a 10 year time horizon.
>
> HPUX, Solaris, Windows 2000," and now you say it's easy to upgrade.
>
> Lee
>

--

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



Dave Taht

2019-10-05 18:19:43 CET

Lee Howard <lee _at_ asgard _dot_ 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.

>
> 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
>
> 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.  Gert Doering 2019-10-05 19:03:21 CET Hi, On Sat, Oct 05, 2019 at 04:13:48PM +0000, Michel Py wrote: > > Nick Hilliard wrote : > > The cost of making 240/4 usable is to update every device on the planet, > > including legacy ipv4 stacks. > > No it is not. It costs nothing to the Internet, it only costs to those who chose to use it as private address space. > More FUD. It's not "private address space" unless designated as such. But yeah, if only used internally, you just need to upgrade all those OS/2, Win95, WinXP systems, old internal routers, ... :-) 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  Michel Py 2019-10-05 19:06:57 CET >>> Nick Hilliard wrote : >>> The cost of making 240/4 usable is to update every device on the >>> planet, including legacy ipv4 stacks. >> Michel Py wrote : >> No it is not. It costs nothing to the Internet, it only costs to >> those who chose to use it as private address space. More FUD. > Gert Doering wrote : > It's not "private address space" unless designated as such. Wrong again. It's not public unless given to RIRs to allocate it. FUD++ Michel.  Job Snijders 2019-10-05 19:09:36 CET On Sat, 5 Oct 2019 at 19:07, Michel Py <michel _at_ arneill-py.sacramento.ca _dot_ us> wrote: > >>> Nick Hilliard wrote : > >>> The cost of making 240/4 usable is to update every device on the > >>> planet, including legacy ipv4 stacks. > > >> Michel Py wrote : > >> No it is not. It costs nothing to the Internet, it only costs to > >> those who chose to use it as private address space. More FUD. > > > Gert Doering wrote : > > It's not "private address space" unless designated as such. > > Wrong again. It's not public unless given to RIRs to allocate it. > FUD++ I think what Gert means is that this space has not been designated by IETF/IANA for *any* purpose yet. One way of looking at it is to acknowledge it is neither private nor public space at this moment in time. See the various columns here https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml Regards, Job  ripe@jack.fr.eu.org 2019-10-05 19:19:41 CET What is not FUD is that 240/4 is not currently routable through my home router So, "it costs nothing" .. well, it cost at least a configuration update, more likely a firmware update, and most certainly some hardware upgrade to support it. A pretty expensite "costs nothing", do not you think ? Regards, On 10/05/2019 07:06 PM, Michel Py wrote: >>>> Nick Hilliard wrote : >>>> The cost of making 240/4 usable is to update every device on the >>>> planet, including legacy ipv4 stacks. > >>> Michel Py wrote : >>> No it is not. It costs nothing to the Internet, it only costs to >>> those who chose to use it as private address space. More FUD. > >> Gert Doering wrote : >> It's not "private address space" unless designated as such. > > Wrong again. It's not public unless given to RIRs to allocate it. > FUD++ > > Michel. >  Michel Py 2019-10-05 19:22:09 CET > Dave That wrote : > 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. It's not only the apps, it's the tools and the entire business process that is behind. I am not going to replace a ten million dollar tool to make it IPv6 compatible. Michel.  Michel Py 2019-10-05 19:27:39 CET > ripe _at_ jack.fr.eu _dot_ org wrote : > What is not FUD is that 240/4 is not currently routable through my home router Oh wow, you need 240/4 on your home router ? must be a pretty big home, if you don't have enough with 10/8 Michel.  ripe@jack.fr.eu.org 2019-10-05 19:50:29 CET Well, if someone has to use to to provide some kind of service, someone shall have the possibility to use this service If you are doing a network for yourself, you can use whatever range from 0/0 On 10/05/2019 07:27 PM, Michel Py wrote: >> ripe _at_ jack.fr.eu _dot_ org wrote : >> What is not FUD is that 240/4 is not currently routable through my home router > > Oh wow, you need 240/4 on your home router ? must be a pretty big home, if you don't have enough with 10/8 > > Michel. >  Gert Doering 2019-10-05 20:10:19 CET Hi, On Sat, Oct 05, 2019 at 05:06:57PM +0000, Michel Py wrote: > > Gert Doering wrote : > > It's not "private address space" unless designated as such. > > Wrong again. It's not public unless given to RIRs to allocate it. > FUD++ Uh, no. The IETF decides what it is, and if they say it's private (like they did with RFC1918), then it is. If they say it's "reserved", it's not up for grabs (neither for the RIRs not for any private deployment either). "Not RIR space" does not make it "private", there are at least 3 different states. Before calling FUD on others, please get your facts straight. 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  Sander Steffann 2019-10-05 20:15:45 CET Hi, > Op 5 okt. 2019, om 19:27 heeft Michel Py <michel _at_ arneill-py.sacramento.ca _dot_ us> het volgende geschreven: > >> ripe _at_ jack.fr.eu _dot_ org wrote : >> What is not FUD is that 240/4 is not currently routable through my home router > > Oh wow, you need 240/4 on your home router ? must be a pretty big home, if you don't have enough with 10/8 I must say I have had enough of your snarky remarks. They are very unproductive and do not contribute to this working group in any way. Please refrain from posting unless you have something to contribute please. Cheers, Sander  Lee Howard 2019-10-05 20:31:24 CET On 10/5/19 11:53 AM, Dave Taht wrote: > Lee Howard <lee _at_ asgard _dot_ org> writes: > >> On 10/4/19 4:55 PM, Dave Taht wrote: >>> not being able to get a >>> static IPv6 address out of comcast, my hurricane tunnel getting blocked >>> by netflix, the still-huge prefix sub-distribution problem. The idea of >>> dynamic 2 week prefixes in part of the world prone to earthquakes >>> doesn't work for me... >> I can think of several programmatic ways to deal with that. > ... > > for real use a static ipv6/48 to distribute is needed. Dynamic ipv6 > assignments are fine if you are doing trivial stuff but if ipv6 is ever > to even start to supplant ipv4 it's got to become more static. Or more resilient to renumbering. I didn't mean to suggest that you as a user should have to code your home network. I meant that we (maybe IETF) have not done well at handling the case of "I received a new prefix, and I am the edge router; I need to tell everything else what changed." Thus kicking off RAs, DHCPv6 updates, dDNS updates, and a firewall that understands dynamic prefixing. >> I was thinking about some Hackathon projects to add IPv6 capability to >> open source projects. Seems to me the hardest part is making sure >> there's an adequate test environment. > Hackathons ARE useful tools for getting a short burst of focused work > out of people sharing the same space and time, but too many are thinking > hackathons alone will solve more detailed design, coding and iteration > problems; it's one of those ideas trivializing the costs of "Real > Programming(tm)" that really bugs me nowadays. > > I could share here the detailed project management stuff that went into > cerowrt's run (3 years), or the outline of work we did for > make-wifi-fast - which we've now been at for over 5 years now - 3+ to > get fq_codel to work right on wifi, 2 to rework the API to work for more > devices, and a pointer to the latest work which has been going for 3+ > months now - and for all that we've only accomplished about 1/10th what > we wanted to do, and only on 4 chipsets (most recently intel's ax200 > chips) out of the hundreds. This might make for an interesting WG discussion, getting actual work organized and done. >>>>> 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%. >> (Replying to an item upthread) >> >> APNIC's statistics show that in almost every network that has IPv6, it >> is almost always used. > I pointed to coffee shops as one counter example. If they don't have IPv6, they're not using it. > To the lack of > DHCPv6-PD on android (and I think, IOS) for tethering as another. Based on discussions at IETF, I guess Android is expecting to get multiple IPv6 addresses and reassign as needed. Don't know about IOS. >> Another thought I've had: >> >> One of the reasons small ISPs can't deploy IPv6 is that they don't >> control the features in the CPE, because they don't buy enough. >> >> I know a couple CPE vendors who would be happy to provide a specific >> feature set for a guaranteed purchase of a couple thousand units a >> month. This sounds like a good business to me: if a bunch of small >> ISPs each contract for a specific number of units, but require >> RIPE-554, RFC7084, and RFC8085, we could both get the needed features, >> and get a larger volume discount than they get now. > Yes, the smaller ISPs should join together in a buying > club like that. Tried to get that going in NZ once. Failed. > > tried harder to make the aftermarket do the right thing - the eeros and > google wifi's of the world are doing ok, the bottom part of the market > just copy/pastes whatever's in openwrt at that moment, slaps a label > on it and ships it. So we focused on making the openwrt base as good > as possible. Might be another part of "What the WG should do" discussion. >> Saving$1 per CPE is better than spending $20 for an IPv4 address for >> every new user. Please confirm my math. :) > I always thought that ISPs would invest in their CPE far more than they > have. Free.fr being a shining example! ISPs get paid for modem rentals > and have customer support costs that could be reduced - that should have > been a great ongoing funding source and motivation, alone. > > but I know a few vendors, like evenroute, doing bufferbloat AND ipv6 > right, that have totally failed to crack ISP market thus far. > > and for no reason I can think of, the rental folk don't push out > new hardware OR new software to their users - I think charter made > an effort to get docsis 3.1 stuff out there and retire all the docsis > 2.0 gear in place, but not comcast. > > Secondly none of those ipv6 standards help when you still really need a > real IPv4 address, so yer still out the$20, IF you can buy the /24s you
> need. And there's more ipv6 RFCs left without running, integrated code,
> to support them.

In my experience, accountants run the CPE purchasing, and saving 5¢ per
unit is worth more to them than avoiding 10% of them driving 30 support calls. Same with rentals: why replace when the cost is already completely written off? There are some good reasons (like technical debt dragging on forward competitiveness) to replace. It may be the case that not everyone needs a unique IPv4 address. Several broadband ISPs have deployed DS-Lite, for example. I don't know the business model; do they charge for unique IPv4 addresses when needed? That's sort of back to my other point of aligning expenses and revenues. >> You just mentioned your un-upgradable "OS/2 Warp, MS-DOS, Windows 95, >> HPUX, Solaris, Windows 2000," and now you say it's easy to upgrade. > I didn't say it was "easy to upgrade" in the context of this legacy > gear, I said it was easy to "add" 420m addresses. 240/4 is almost fully > enabled in every OS except windows, for example. Fixed the last bug > in it for linux and openwrt last december. Deploying. 0/8 now. What's the relative level of support for unicast 240/4 and IPv6? > > Yea, people keep missing on this point. IPv6 is not globally reachable > either. To try and clarify: A new IOT device trying to backhaul its > data to 240.0.0.1 doesn't need to have a windows OS also trying to get to > that same address. Is that clearer? A new application can try to use > new IPv4 addresses. Do you mean 240/4 for private connectivity, or 240/4 publicly routed and it's fine for some applications if it's unreachable? Do all routers etc support it? Lee  Michel Py 2019-10-05 20:31:25 CET > Sander Steffann wrote : > I must say I have had enough of your snarky remarks. They are very > unproductive and do not contribute to this working group in any way. Please > refrain from posting unless you have something to contribute please. Then unsubscribe me. What is very unproductive is the last twenty years you have failed to make IPv6 the prevalent protocol. That's half one's career, and you will spend the other half failing again. Great job. An entire career failing. Employers like people who achieve goals. Good luck. Michel.  Lee Howard 2019-10-05 20:42:47 CET On 10/5/19 12:06 PM, Dave Taht wrote: > Lee Howard <lee _at_ asgard _dot_ org> writes: > > >> 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. If you have a dedicated box or service card for NAT, you have a specific NAT expense. If you can buy a smaller box for half the cost, you've saved a specific amount of money. I know of mobile carriers who NATted every Internet connection in IPv4, and have halved their capital expense on NAT. >> 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. I've had inquiries along these lines, and written proposals. >> 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. Here's my assessment: https://www.retevia.net/why-is-ipv6-faster/ >> 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. "Deployable"? It's been deployed by the millions. Everyone who's done it says it was mostly labor. >> 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 exaustion 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 Interesting! > >> selling addresses), inLOCAL_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.

I'm not sure what you're calling "BS." Obviously $30,000 was a made-up number for the example. I don't know what "dangling set of apps" you mean that can't be converted, especially in the context of "How much would it cost to add IPv6 support?" >> 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. Fewer IPv4 addresses are needed in the context of MAP or 464xlat. >> 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? Not that I know of. If there's interest, I'll support, maybe organize. Lee  Job Snijders 2019-10-05 21:02:50 CET On Sat, Oct 05, 2019 at 06:31:25PM +0000, Michel Py wrote: > > Sander Steffann wrote : > > I must say I have had enough of your snarky remarks. They are very > > unproductive and do not contribute to this working group in any way. > > Please refrain from posting unless you have something to contribute > > please. > > Then unsubscribe me. What is very unproductive is the last twenty > years you have failed to make IPv6 the prevalent protocol. That's half > one's career, and you will spend the other half failing again. Great > job. An entire career failing. Employers like people who achieve > goals. Good luck. Michel, many of us are frustrated with the current state of affairs (for different reasons, however that isn't relevant). This frustration, those rage knots in your stomache, don't mean we should permit ourselves to submit unfiltered bitterness into each other's mailboxes. If the IPv4 vs IPv6 tussle is interpreted as a culture war, I think by now all sides are thoroughly confused and have no idea what is going on. Is this still part of a long game? Are we at a tipping point, just one final barrier, or wasting our breath? It is really hard to tell at times. I say "all sides" because there are more than 2 factions. There are people who like neither IPv4 or IPv6, or just one of the two. In this landscape there are quite some folks have staked their careers on either one of the address families, and even such circumstances we should be careful to avoid rhetoric devices like ad-hominem. Once deployed you immediately lost whatever debate was going on. In such instances it may be time to take a break. There are folks who have genuine belief systems in which they consider spending half of their career an absolute necessity towards some their personal higher goal. A friend recently told me "there's a thin line between passion and madness". In such a situation, the best I hope for, is that all sides at least acknowledge the possiblity that they themselves were the ones spending energy in a counter-productive direction. Before hitting "send" it is always good to consider what other interpretations of the email-being-replied-to are possible, consider what the author may have meant to say, and how your reply will affect them and the other readers. So, either strive to be excellent to each other, or refrain from posting. Kind regards, Job  Anton Rieger 2019-10-05 21:24:13 CET On Sat, Oct 05, 2019 at 08:10:19PM +0200, Gert Doering wrote: >Uh, no. The IETF decides what it is, and if they say it's private >(like they did with RFC1918), then it is. > >If they say it's "reserved", it's not up for grabs (neither for the RIRs >not for any private deployment either). > >"Not RIR space" does not make it "private", there are at least 3 different >states. Best examples are 1.1.1.1 and 5.5.5.5 Anton  Michel Py 2019-10-05 21:44:10 CET Hi Job, > Job Snijders wrote : > If the IPv4 vs IPv6 tussle is interpreted as a culture war, It is war, but I don't think it is a matter of culture. After all, 20 years ago we almost all were in the same boat, more or less. Most of us believed that IPv6 could replace IPv4 in a reasonable number of years, and all of us were wrong, because it did not. It have become a war because of money, and the outcome will be decided by money, not by ideals. There are people who have admitted that, and people who have not and keep waging the war as they could still win it. Time to be nice has come, and gone. The IPv6 camp has clearly stated that their goal is to win the war. Battle time. Michel.  Marc Blanchet 2019-10-05 21:56:18 CET On 5 Oct 2019, at 15:44, Michel Py wrote: > Hi Job, > >> Job Snijders wrote : >> If the IPv4 vs IPv6 tussle is interpreted as a culture war, > > It is war, but I don't think it is a matter of culture. After all, 20 > years ago we almost all were in the same boat, more or less. Most of > us believed that IPv6 could replace IPv4 in a reasonable number of > years, and all of us were wrong, because it did not. you are right Michel, it hasn’t yet. I did not have any number of years in my mind, but I was sure that it would quite long. The footprint of IPv4 Internet (including OS, devices, software, networks, …) is so so large, that it sure will take a loooooong time. Cobol is still in use… I don’t think IPv4 will be dead in my lifetime. But that does not mean we should not be working on its replacement to sustain the growth. To me IPv6 is the only viable solution. It has gone through pretty hard infancy, but is improving. Many of its great new ideas has been almost abandonned, but the larger address space remains a clear win over IPv4. To me, this whole discussion is moot. IPv6 has not yet took over IPv4 yet. But that does not mean we shall not continue working on improving IPv6 and deploying it and use it. Up to now, I have only see an increase of the number of nodes/trafic over IPv6, by any metric or monitoring system I’ve seen. The increase rate is not as most of us would like to be, but still positive. To me, if we see a decrease of usage of IPv6 over some significant period of time, then we shall discuss about the failing of IPv6. But we are not yet there. Regards, Marc. > > It have become a war because of money, and the outcome will be decided > by money, not by ideals. There are people who have admitted that, and > people who have not and keep waging the war as they could still win > it. > > Time to be nice has come, and gone. The IPv6 camp has clearly stated > that their goal is to win the war. Battle time. > > Michel.  Roger Jørgensen 2019-10-05 21:57:40 CET ... I guess this "war" is why some people want to make ipv6 as much like ipv4 as possible? Only . vs : and hex vs pure number as the only difference? ------- Roger Jørgensen rogerj _at_ gmail _dot_ com On Sat, Oct 5, 2019, 21:44 Michel Py <michel _at_ arneill-py.sacramento.ca _dot_ us> wrote: > Hi Job, > > > Job Snijders wrote : > > If the IPv4 vs IPv6 tussle is interpreted as a culture war, > > It is war, but I don't think it is a matter of culture. After all, 20 > years ago we almost all were in the same boat, more or less. Most of us > believed that IPv6 could replace IPv4 in a reasonable number of years, and > all of us were wrong, because it did not. > > It have become a war because of money, and the outcome will be decided by > money, not by ideals. There are people who have admitted that, and people > who have not and keep waging the war as they could still win it. > > Time to be nice has come, and gone. The IPv6 camp has clearly stated that > their goal is to win the war. Battle time. > > Michel. > >  S.P.Zeidler 2019-10-05 22:10:21 CET Thus wrote Michel Py (michel _at_ arneill-py.sacramento.ca _dot_ us): > Time to be nice has come, and gone. The IPv6 camp has clearly stated that their goal is to win the war. Battle time. What theatralics. I want a 'net where I can do end-to-end, and where new things can happen. That can't be done with IPv4 (only) because v4 doesn't have sufficient addresses for this world. If some people want to stay IPv4-only forever: sure, if that makes you happy, just don't expect the rest of the world to hobble themselves so you won't miss out. Regarding your "I will blacklist your resume": you greatly overestimate your relevance. When I started networking the money was with OSI. The money did not win. Companies make bad decisions and fail. regards, spz -- spz _at_ serpens _dot_ de (S.P.Zeidler)  Job Snijders 2019-10-05 22:16:01 CET On Sat, Oct 05, 2019 at 03:56:18PM -0400, Marc Blanchet wrote: > Up to now, I have only see an increase of the number of nodes/trafic > over IPv6, by any metric or monitoring system I’ve seen. The increase > rate is not as most of us would like to be, but still positive. To me, > if we see a decrease of usage of IPv6 over some significant period of > time, then we shall discuss about the failing of IPv6. But we are not > yet there. I've observed IPv6 hitting a plateau (even a slight decrease!) in usage of IPv6 across multiple large networks measured over significant time. A publicly accessible graphs produced from the AMS-IX platform is available here: https://stats.ams-ix.net/sflow/ether_type.html IPv4 vs IPv6 is neatly normalized by presenting the traffic as a percentage rather than some absolute measure. I'm attempting to collect information from other platforms as well because I think this type of graph helps compare apples to apples. Growth of IPv6 traffic in absolute units is expected, if we consider IPv6 traffic usage a function of overall Internet traffic usage. Internet traffic appears to grow steadily. However, if IPv4 and IPv6 grow at the same rate, my interpretation would be that IPv4 use is not declining, thus IPv6 isn't growing, and we should indeed be discussing the current failing of IPv6. Some may argue that IPv6 traffic doesn't replace IPv4 traffic, that IPv6 traffic is new apps or new demand, but in a Happy Eyeballs / dualstack / nat64 world I'd consider that somewhat unlikely. Happy to hear other people's thoughts! Kind regards, Job ps. Before we venture into a tit-for-tat where we trade pictures of decline (e.g. IXP stats) against pictures of growth (google stats), I'd like to learn more why we see what we see in the current decline graphs.  Michel Py 2019-10-05 22:30:40 CET Marc, long time no see indeed ;-) > Marc Blanchet wrote : > To me IPv6 is the only viable solution. To me IPv4 is the only viable solution until a replacement for IPv6 is found. You know what I do for a living. Where are the US$ 2B I need to dual-stack ?
I just can't afford it.

> but the larger address space remains a clear win over IPv4.

Not to everyone.

> To me, this whole discussion is moot. IPv6 has not yet took over IPv4 yet.

I saw that one coming a long time ago. Was a bit of a shock.

>  But that does not mean we shall not continue working on improving IPv6 and deploying it and use it.

You do what you have to do to insure your survival, and so do I.

At this point in time, the IPv6 zealots, by doing everything they can to kill IPv4, are a nuisance that has to be eliminated.

This 240/4 as an extension of RFC1918 thing is the perfect example of it. What does it cost IPv6 ? nothing. Why do the zealots torpedo it ? because anything that hurts IPv4 is good for them, or so they think. Net result : organizations that need more than 10/8 are now (and they are plenty of examples) squatting un-announced DoD space such as 30/8.

Then keep your dogs on leash. We can bark and bite, too.
I am defending my ecosystem, and I am tired of the rethoric that IPv6 will take the world over. It will not.

Michel.



Carlos Friacas

2019-10-05 22:40:57 CET


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 :
> And the full text :
> Serious work, paid by ICANN.
>
> Michel.
>
>

Michel Py

2019-10-05 23:02:27 CET

> Job Snijders wrote :
> I've observed IPv6 hitting a plateau (even a slight decrease!) in usage
> of IPv6 across multiple large networks measured over significant time.

I was expecting more than not even 3% IPv6 at AMSIX. I don't call it "significant time" yet.
IMHO, it will take a few more years before we get a clear picture.
IPv6 will plateau, I just don't think we know where and when yet. Or do we ?

> However, if IPv4 and IPv6 grow at the same rate, my interpretation would be that IPv4 use is not declining,
> thus IPv6 isn't growing, and we should indeed be discussing the current failing of IPv6.

I did not start this thread, but it is time to acknowledge that talks of 100% IPv6 are not something that should be on the table at this time.

> ps. Before we venture into a tit-for-tat where we trade pictures of decline (e.g. IXP stats) against pictures
> of growth (google stats), I'd like to learn more why we see what we see in the current decline graphs.

Do you measure what is happening on private interconnects ? MMR traffic ? I would guess that a good part of the IPv6 traffic is between large players, and that somehow they may have changed their peering scheme ?

Michel.



Michel Py

2019-10-05 23:16:39 CET

> 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.

>> 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 :-)

> 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. Michel.  'Job Snijders' 2019-10-05 23:20:48 CET On Sat, Oct 05, 2019 at 09:02:27PM +0000, Michel Py wrote: > Do you measure what is happening on private interconnects ? MMR > traffic ? Yes, looking at stats at NTT (a network which basically is only private interconnects), I see a similar pattern as we observe at AMS-IX. I'll see what detalis I can share. It would be nice if more players would share a normalised overview of IPv4 vs IPv6 percentages, just like AMS-IX does. > I would guess that a good part of the IPv6 traffic is between large > players, and that somehow they may have changed their peering scheme ? I find it hard to believe that two networks would end up exchanging IPv6 traffic over private connections, and at the same time keep IPv4 traffic on public IXPs or transit. That doesn't seem to align with the usual economic or security drivers behind peering. Ofcourse we can't exclude the possiblity this happens, but I am not aware of anyone who explicitly configured things to be that way. I'm beginning to suspect that the "there is lots of IPv6 traffic!" some folks report on is mostly between handsets (strictly controlled by the mobile provider) and a select few Big Content on-net cache devices. Even if we consider such an intranet IPv6 deployment part of the big-I Internet, it doesn't strike me as healthy. I posit: the further an IP packet has to travel, the less likely it is to be an IPv6 packet. Kind regards, Job  Carlos Friacas 2019-10-05 23:29:48 CET  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. > > Michel Py 2019-10-06 00:26:03 CET >> Michel Py wrote: >> Do you measure what is happening on private interconnects ? MMR traffic ? > Job Snijders wrote : > Yes, looking at stats at NTT (a network which basically is only private interconnects), > I see a similar pattern as we observe at AMS-IX. I'll see what detalis I can share. I have to admit that your figures are a bit of a surprise; 2.5% IPv6 average. Thanks for sharing. > It would be nice if more players would share a normalised overview of > IPv4 vs IPv6 percentages, just like AMS-IX does. Indeed. > I find it hard to believe that two networks would end up exchanging IPv6 traffic over private connections, > and at the same time keep IPv4 traffic on public IXPs or transit. That doesn't seem to align with the usual > economic or security drivers behind peering. Of course we can't exclude the possiblity this happens, but I > am not aware of anyone who explicitly configured things to be that way. I was not aware of any either, I thought in Europe it could have been different. In the US, where would the traffic between Verizon wireless (heavy IPv6) and Google (IPv6 enabled) go ? In multiple MMRs / private interconnects ? > I'm beginning to suspect that the "there is lots of IPv6 traffic!" some folks report on is mostly between > handsets (strictly controlled by the mobile provider) and a select few Big Content on-net cache devices. Indeed. Just take Verizon wireless out and half of the IPv6 traffic disappears. Well, not half but certainly a sizable chunk. Google confirms this : https://www.google.com/intl/en/ipv6/statistics.html If you zoom in, you can see a clear weekly pattern of about 5%, which is clearly that at the office people use their office computer to Google during the week, and during the weekend thy use their mobile or their home ISP, Comcast being IPv6 heavy contributing to that. Same thing happens at new year : everyone is at home, so the IPv6 percentage is higher. Can you zoom your AMS-IX graphs so we can see if you have the same phenomenon ? A monthly IPv6 graph with the top of the graph being 3% ? Just right there, we can see clearly that if Google were to go IPv6-only, they would lose 1/6th of their traffic. (that is, IF the top of the graph was 100% IPv6, which it is not. If Google were to go IPv6-only today, they would lose 70% of their traffic). I suspect that the people in charge have made that analysis and that they are not going to lose that much of a customer base, especially when the base in question is business. > Even if we consider such an intranet IPv6 deployment part of the big-I Internet, it doesn't strike me as healthy. It's why I call it a niche market. Only on environments that are completely controlled by the provider, where the user has no choice (and does not have a clue, anyway). It's an island. The bar is on the beach, and they keep it well stocked (CDN cache) so the booze flows in abundance, but it does not get out much. Healthy ? depends who you are. For them, I think it is. They have the customer completely locked. > I posit: the further an IP packet has to travel, the less likely it is to be an IPv6 packet. +1 Michel.  Kai 'wusel' Siering 2019-10-06 00:38:14 CET Am 05.10.19 um 22:30 schrieb Michel Py: > This 240/4 as an extension of RFC1918 thing is the perfect example of it. If 240/4 is to be given a different status than "reserved", the only valid option is "public unicast", spread across the RIRs as recovered space. As has been stated here may times, IPv4 is here to stay, so it's vital that relevant amounts of "new" space are put into the public pool. > Net result : organizations that need more than 10/8 are now (and they are plenty of examples) squatting un-announced DoD space such as 30/8. Maybe someone should tell them about IPv6 then. -kai  Enno Rey 2019-10-06 00:43:39 CET Hi, On Sun, Oct 06, 2019 at 12:38:14AM +0200, Kai 'wusel' Siering wrote: > > > Net result : organizations that need more than 10/8 are now (and they are plenty of examples) squatting un-announced DoD space such as 30/8. > > Maybe someone should tell them about IPv6 then. or about the rumours that the DoD has been encouraged to make some of its address space available to ARIN ;-) cheers Enno -- Enno Rey @Enno_Insinuator  Michel Py 2019-10-06 01:05:43 CET >> Michel Py wrote : >> This 240/4 as an extension of RFC1918 thing is the perfect example of it. > Kai 'wusel' Siering wrote : > If 240/4 is to be given a different status than "reserved", the only valid option is "public unicast", I agree with unicast, but not public. > spread across the RIRs as recovered space. I have to disagree with that. I would agree if it was an achievable goal, but it is not. The multiple attempts over the years to make this space available have all failed, and there is a reason for it : it would create a second-class address space, that the devices with unpatched kernels would not be able to access. In other words : it would require an update to every device that connects to the Internet, which is too much hassle. > As has been stated here may times, IPv4 is here to stay, so it's vital > that relevant amounts of "new" space are put into the public pool. Maybe so, but that battle can not be won. Besides, a /4 would buy how much time ? a year or two ? it's futile. Focus on things that have a chance. > Enno Rey wrote : > or about the rumours that the DoD has been encouraged to make some of its address space available to ARIN ;-) The smiley was right on ! DoD has a trillion dollar budget, even at1000 / IP it would not make a difference.
They don't know anything that is less than a billion ;-)

I had that question once, actually.
- 10/8 is too small, which of the un-announced DoD blocks is the best to squat ?
- You must be kidding, you want to squat IP space from people who have nukes and have used them on civilians before ?
- Oh, they can't nuke us. They have a big base 1/4 mile away.
- Oh great, now you are telling me that they have a freaking brigade next to your backyard and you are going to hijack one of their class A?
- Squat, not hijack. Yeah, they'll never know about it.

30/8. There are so many orgs using it that the DoD will never release it.

Michel.



Alexander Koeppe

2019-10-06 01:26:26 CET

> Am 04.10.2019 um 08:56 schrieb Carlos Friaças via ipv6-wg <ipv6-wg _at_ ripe _dot_ 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.


Sander Steffann

2019-10-06 01:45:21 CET

Hi Michael,

> Time to be nice has come, and gone. The IPv6 camp has clearly stated that their goal is to win the war. Battle time.

If you want a war that is your choice, but please go and fight it somewhere else. RIPE mailing lists are a place to be constructive and, as Job said, excellent to each other.

Cheers,
Sander



Michel Py

2019-10-06 01:53:06 CET

> Sander Steffann wrote :
> If you want a war that is your choice, but please go and fight it somewhere else. RIPE
> mailing lists are a place to be constructive and, as Job said, excellent to each other.

Read the rest of my posts. I did not start the war. I did not start this thread.
There are two ways to lose a war : lack of funds, and lack of courage. I have both.

The war is global. Who do you think you are to tell me to take it somewhere else ?
The chair of a mighty WG that has managed, in 20 years, to capture a whole 2.5% of the Internet traffic right in your own backyard at AMS-IX ?

Kick me out of the mailing list, if you have the power to do so.

Michel.



ripe@jack.fr.eu.org

2019-10-06 01:53:09 CET

100% of internet will happen
100% of all networks will not

On 10/05/2019 11:02 PM, Michel Py wrote:
> I did not start this thread, but it is time to acknowledge that talks of 100% IPv6 are not something that should be on the table at this time.



Mikael Abrahamsson

2019-10-06 05:10:52 CET

On Sat, 5 Oct 2019, 'Job Snijders' wrote:

> I posit: the further an IP packet has to travel, the less likely it is
> to be an IPv6 packet.

Looking at who has deployed IPv6 and how these people communicate, this is
most likely true.

IPv6 is most common today on eyeball<->CDN traffic. Looking at what kind
of companies have deployed IPv6 to eyeballs, this is mostly larger ISPs.
So we have a subset of ISPs and a subset of CDNs that both have deployed
IPv6, and both these subsets tend to communicate over direct
interconnections so these stats are not public.

A lot of the organisations that were eager to deploy IPv6 have done so.
Large companies with significant engineering resources that had to fight
uphill to get evertthing to work. The organisations deploying IPv6 now
might be less eager, but they will also have less struggle. A significant
amount of development work to support IPv6 has been done already. It's
still non-trivial work, but it should be easier than before.

I also note clustering. Lots of companies are "followers". They will not
be the first one to do something, but instead will copy someone else. In
some countries there is lots of IPv6, and in others there isn't. I see the
same way with DNSSEC validation and other technologies.

The good thing now is that it's not useless to deploy IPv6. As soon as you
turn on IPv6 to eyeballs, you get significant IPv6 traffic. I've heard
people mention 50-70%, which is what my household also is at (mostly
streaming video from CDNs).

I don't think IPv6 has failed, I just think it's going to take a long
time, and especially the last 10% is going to take a really really long

--
Mikael Abrahamsson    email: swmike _at_ swm.pp _dot_ se



Carlos Friacas

2019-10-06 10:30:07 CET


Hi Alexander, All,

Github is now owned by Microsoft.
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

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 _at_ ripe _dot_ 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.
>

Gert Doering

2019-10-06 10:53:58 CET

Hi,

On Sat, Oct 05, 2019 at 09:24:13PM +0200, Anton Rieger wrote:
> On Sat, Oct 05, 2019 at 08:10:19PM +0200, Gert Doering wrote:
> >Uh, no.  The IETF decides what it is, and if they say it's private
> >(like they did with RFC1918), then it is.
> >
> >If they say it's "reserved", it's not up for grabs (neither for the RIRs
> >not for any private deployment either).
> >
> >"Not RIR space" does not make it "private", there are at least 3 different
> >states.
>
> Best examples are 1.1.1.1 and 5.5.5.5

1.1.1.1 is APNIC space, which was very officially given to CF and
documented as such.

inetnum:        1.1.1.0 - 1.1.1.255
netname:        APNIC-LABS
descr:          APNIC and Cloudflare DNS Resolver project
descr:          Routed globally by AS13335/Cloudflare
descr:          Research prefix for APNIC Labs

5.5.5.5 is part of Telefonica's allocation

inetnum:        5.4.0.0 - 5.7.255.255
netname:        DE-MEDIAWAYS-20120425
country:        DE
org:            ORG-TDG4-RIPE

... and anyone using it for their private VPN is squatting on address
space not belonging to him (and yes, I think this was a fairly bad
decision "back when this space was still free" - even then it was not
"up for grabs").

Fairly easy this.  If it's not yours, or designated as "free for all",
you do not use it.  Otherwise the ghosts of the Internet will come and
haunt you.

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


Gert Doering

2019-10-06 10:59:51 CET

Hi,

On Sun, Oct 06, 2019 at 12:38:14AM +0200, Kai 'wusel' Siering wrote:
> Am 05.10.19 um 22:30 schrieb Michel Py:
> > This 240/4 as an extension of RFC1918 thing is the perfect example of it.
>
> If 240/4 is to be given a different status than "reserved", the
> only valid option is "public unicast", spread across the RIRs as
> recovered space. As has been stated here may times, IPv4 is here
> to stay, so it's vital that relevant amounts of "new" space are put
> into the public pool.

I'd actually say "private" is a better denomination.

To make this useful as "public unicast", you need to upgrade *everything*
in the path between a device using 240/4 and "whatever it wants to talk to",
otherwise - so, if RIPE were to give out a subnet of 240/4, it would not
be very useful for "Internet" usage.

to make sure all devices support 240/4, it's all under your own control
and can be done.

(Would I do it?  No... anything old won't grow support for it, and anything
*new* can do IPv6 for new deployments - on islands, with gateways in
between, but incidentially that's the only way a 240/4 deployment could
succeeed as well.  But hey, not my career to bet on 240/4 being useful :-) )

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


2019-10-06 11:39:14 CET

Carlos Friaças via ipv6-wg <ipv6-wg _at_ ripe _dot_ 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
--
----------------------------------------------------------------------------
| Delbrueckstr. 41    | 12051 Berlin, Germany           | +49-151-18721264 |
| http://blog.quux.de | jabber: jenslink _at_ quux _dot_ de        | ---------------  |
----------------------------------------------------------------------------



Nick Hilliard

2019-10-06 13:30:41 CET

Michel Py wrote on 06/10/2019 00:53:
> The war is global. Who do you think you are to tell me to take it
> somewhere else ?
> The chair of a mighty WG that has managed, in 20 years, to capture a
> whole 2.5% of the Internet traffic right in your own backyard at
> AMS-IX ?
>
> Kick me out of the mailing list, if you have the power to do so.

Michel,

It's not fully clear what points you're trying to make here.  Is it
that the RIPE Address Policy working group is responsible for global
ipv6 adoption?  Or that Sander is personally responsible for AMS-IX
member IPv6 adoption policy?  Or that Sander has any interest other than
constructive discussion on RIPE working group mailing lists?

This looks like a personal attack on Sander. This brings down the tone
of the WG mailing lists and is terribly unnecessary.  Please take this
elsewhere.

Nick



Carlos Friacas

2019-10-06 17:18:40 CET

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 _at_ ripe _dot_ 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
> --
> ----------------------------------------------------------------------------
> | Delbrueckstr. 41    | 12051 Berlin, Germany           | +49-151-18721264 |
> | http://blog.quux.de | jabber: jenslink _at_ quux _dot_ de        | ---------------  |
> ----------------------------------------------------------------------------
>

Olivier MJ Crepin-Leblond

2019-10-06 17:33:21 CET

Dear Michel,

On 04/10/2019 17:16, Michel Py wrote:
> 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.

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. For example, Windows 2000 end of support was
as far back as July 13, 2010.
https://blogs.technet.microsoft.com/education/2009/11/10/windows-2000-end-of-life/

That means no security updates. With today's Internet being nothing like
the Internet back in 2000, is this really reasonable? Unless, of course,
the hardware is behind some modern firewalls.

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

Kindest regards,

Olivier


2019-10-06 18:02:39 CET

Carlos Friaças via ipv6-wg <ipv6-wg _at_ ripe _dot_ net> writes:

> Hi,
>
> Fine, i get it: It's not only Microsoft and Cisco.

I don't think Microsoft is involved how GitHub operates it's
network.

> But, imho, such list of 'gaps' is very, very useful!

See my presentations. the update slide to my last presentation would
look like this (in the source}

\begin{frame}
\frameritle{Update RIPE 77}

\end{frame}

What would such a list accomplish?

I put answers in three categories:

2 - Your call is very important to us. We are working on it.
3 - Got away we'll never do IPv6

I think that 1 and 3 are the most honest answers you'll get at that 2
is just a polite form of answer 3.

BTW: You'll will often get answers including the phrase "You are the

Jens
--
----------------------------------------------------------------------------
| Delbrueckstr. 41    | 12051 Berlin, Germany           | +49-151-18721264 |
| http://blog.quux.de | jabber: jenslink _at_ quux _dot_ de        | ---------------  |
----------------------------------------------------------------------------



S.P.Zeidler

2019-10-06 18:13:03 CET

Thus wrote Mikael Abrahamsson (swmike _at_ swm.pp _dot_ se):

> I don't think IPv6 has failed, I just think it's going to take a long time,
> and especially the last 10% is going to take a really really long time.

At some point in time IPv4 code will rot, and see too little testing to
be still useful, and around then v4 will die pretty quickly.

Given we'll have enterprise walled gardens with v4 inside for a long time,
that indeed will take decades. If you plan projects that span more than
one decade, making sure it's IPv6 capable will at least save you money
in the long run, because enterprise-only features come at a premium.

regards,
spz
--
spz _at_ serpens _dot_ de (S.P.Zeidler)



Uroš Gaber

2019-10-06 18:24:48 CET

On Sat, Oct 5, 2019 at 10:31 PM Michel Py <
michel _at_ arneill-py.sacramento.ca _dot_ us> wrote:

> Marc, long time no see indeed ;-)
>
> > Marc Blanchet wrote :
> > To me IPv6 is the only viable solution.
>
> To me IPv4 is the only viable solution until a replacement for IPv6 is
> found.
>
>

But what other solution do you see, a brand new protocol that takes another
x years for adoption, that will in far end still cause dual or better yet
triple stack deployment?

IPv4 will not be dead any time soon, this I think is clear to anyone
dealing in network deployment, but again it (should) also be clear to these
same people that to sustain and keep the anywhere-to-everywhere
connectivity the IPv6 is the only viable option.

To not be mistaken for me being on any of the "sides" for IPv6 or IPv4,
currently I depend heavily on IPv4, but in the meantime I also deploy IPv6
in a safe (for my taste and acceptance) fashion, that is testing is key,
should I conclude in my tests that a certain deployment doesn't work
perfectly I delay it if possible.

Again there is no perfect solution, we are just so used to doing things a
certain way that we do them subconsciously and don't even think about the
needed steps for certain things, where as when we deploy IPv6 for a certain
service it usually needs us to think about things to make everything work
right.

IMHO there should be more work put into replacing/extending SMTP than
thinking over IPv6, as most of the complaints I've seen were about IPv6
mail server deployment and problems with blacklists etc. "Fix SMTP" to
annihilate SPAM and these problems will disappear too.

Uros


2019-10-06 18:32:18 CET

"S.P.Zeidler" <spz _at_ serpens _dot_ de> writes:

> Given we'll have enterprise walled gardens with v4 inside for a long time,
> that indeed will take decades. If you plan projects that span more than
> one decade, making sure it's IPv6 capable will at least save you money
> in the long run, because enterprise-only features come at a premium.

A couple of years ago I did an IPv6 workshop for a not so small SAP
outsourcing company- I told them "what ever you do make sure your that
everything you buy is IPv6 capable."

About a year later I was told that they can't implement v6 because they
just bought a internal cloud thing that did not support IPv6.

Jens
--
----------------------------------------------------------------------------
| Delbrueckstr. 41    | 12051 Berlin, Germany           | +49-151-18721264 |
| http://blog.quux.de | jabber: jenslink _at_ quux _dot_ de        | ---------------  |
----------------------------------------------------------------------------



Wolfgang Zenker

2019-10-06 20:34:36 CET

Hi Jen,

* Jen Linkova <furry13 _at_ gmail _dot_ com> [191005 03:46]:
> On Fri, Oct 4, 2019 at 5:41 AM Wolfgang Zenker <zenker _at_ punkt _dot_ de> wrote:
>> ... the default network at RIPE Meetings is the dual-stack network, with
>> the IPv6-only (NAT64) network as a barely used extra which is "supported
>> on a best effort basis". With the effect that almost no-one except a few
>> "ipv6 zealots" uses it. This tells me that a significant part of the
>> RIPE community does not only consider this setup "not production ready"
>> but expects an amount of breakage so huge that it's not acceptable to
>> try it out and see what would actually break (while still offering a
>> dual-stack network as a fallback, of course).

> I'm not sure I can follow the logic here. What you are saying about
> 'do not consider production ready' would have been true if users made
> a decision which SSID to connect every time (and that decision took
> into account the protocol version). But it's clearly not the case.
> First time attendees connect to whatever SSID is specified in the
> booklet and/or has the most intuitive name. Returning attendees let
> their laptops/phones connect to SSID their devices remember.

> There is an SSID which has been there for years, which is printed on
> the booklets etc and it's name matches the meeting name.
> And there are other SSIDs - which are not listed in the booklet, their
> names are longer (which for MacOS at least might mean that they are
> shown *below* the main one in the list) etc. I'm sure that even if all
> of them were dual-stack, the main one would have attracted the vast
> majority of the userbase.

I guess you misunderstood what I was trying to say here. For years we
have had the "default network" (dual stack) and the "experimental?"
network (ipv6 + NAT64). And for years some people have asked to make
the ipv6/nat64 network the "default network" and give a different SSID
to the dual stack network, with the intention to see real usage on the
ipv6-only network (which would happen because people are lazy). That
should enable us to find any remaining problems quickly, and should
hopefully show to the users that IPv6 is something that works and is
nothing to be afraid of.
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".

>> [..]
>> I maybe wouldn't call the IPv6 WG "failed", but it clearly still has a
>> long way to go until we can claim "mission accomplished".

> I do  not think anyone promised it's going to be easy ;)

> On a more serious note, two things:
> 1) I quickly checked the 2013 survey. It does not even mention IPv6.
> Are you still calling it 'no progress' and 'failure'? ;)
> 2) By lucky coincidence we have  a slot in Rotterdam to discuss the
> working group strategy and future. Let's talk about it.

Seeing that timeslot on the agenda was actually one reason for me to

Greetings,
Wolfgang



Kai 'wusel' Siering

2019-10-07 00:05:05 CET

Moin,

am 06.10.19 um 10:59 schrieb Gert Doering:
> Hi,
>
> On Sun, Oct 06, 2019 at 12:38:14AM +0200, Kai 'wusel' Siering wrote:
>> If 240/4 is to be given a different status than "reserved", the
>> only valid option is "public unicast", spread across the RIRs as
>> recovered space. As has been stated here may times, IPv4 is here
>> to stay, so it's vital that relevant amounts of "new" space are put
>> into the public pool.
> I'd actually say "private" is a better denomination.
>
> To make this useful as "public unicast", you need to upgrade *everything*
> in the path between a device using 240/4 and "whatever it wants to talk to",
> otherwise - so, if RIPE were to give out a subnet of 240/4, it would not
> be very useful for "Internet" usage.

I didn't say it would be a quick win; I'm aware of the issues. 240/4 space
would remain of limited reachability for the forseeable future. After
being declared to become public space via an RFC, devices that still
issue over time, though.

Rationale: an internal network needing more than 16 million IPv4 addresses
(10/8) does have the power to solve their addressing needs with IPv6. This
isn't true for newcomers that have to deal with old players not enabling v6.

Please note: I'm not proposing do touch 240/4, 0/8 or 127/8, but _if_ those
are touched, they should be given to the public.

Regards,
-kai



Michel Py

2019-10-07 04:37:45 CET

> 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.



Michel Py

2019-10-07 05:00:41 CET

> Uros Gaber wrote :
> But what other solution do you see, a brand new protocol that takes another x years for adoption,
> that will in far end still cause dual or better yet triple stack deployment?

No. It has to be a single-stack protocol fully backwards compatible. Dual-stacking is the fatal flaw. In the old days, the thinking was something like "oh everyone will dual-stack for 2 or 3 years, and then IPv4 will die". The problem is, we are 20 years into it already and possibly another 20 years going forward. Dual-stacking for 40 years is not a solution.
Yes, it will take decades, especially since it is not even started. I have all the time in the world.

> IPv4 will not be dead any time soon, this I think is clear to anyone dealing in network deployment,

I don't think it is to everyone. I don't know if you read Nanog, do you know what the latest idea an IPv6 crackhead came up with to accelerate deployment ?
Taxing IPv4. A \$2/mo/per IP tax, worldwide.
https://mailman.nanog.org/pipermail/nanog/2019-October/103279.html
https://mailman.nanog.org/pipermail/nanog/2019-October/103280.html
I'm guessing that what comes next is a constitutional amendment to prohibit IPv4.

> but again it (should) also be clear to these same people that to sustain and keep
> the anywhere-to-everywhere connectivity the IPv6 is the only viable option.

It's not even on the agenda.
I don't have to be ready. I am quite happy in my dinosaur swamp with my dinosaur friends, my dinosaur supply chain, my dinosaur customers, and my dinosaur transit providers.
My swamp is quite big, too. It's called the Internet.
The asteroid that was supposed to extinct us came, 4 years ago in the ARIN region. Did not hit anybody I know. Did not even feel any heat or tremors.
The extinction event did not happen.

I don't need the anywhere-to-everywhere connectivity. As a matter of fact, if the Internet becomes balkanized and v4 and v6 split, I would not mind a bit. The IPv4 ecosystem is big enough to survive on its own for the next 30 years.

There are plenty of dinosaurs left, and a lot of them have pretty big teeth. Who's next on my dinner menu ?

Michel.



Michel Py

2019-10-07 06:07:10 CET

> Kai 'wusel' Siering
> Rationale: an internal network needing more than 16 million IPv4 addresses (10/8) does have the power to solve their
> addressing needs with IPv6. This isn't true for newcomers that have to deal with old players not enabling v6.

I do not agree because it does not fit my use-case, but this is the best argument I have heard for many years.

Keep in mind though : your idea is great, but it has been tried many times, for more than a decade, including by people who are respected players, big shots, and have serious clout, and it has repeatedly failed. What makes you think that you can make it work ? Everyone has tried, everyone has failed. Multiple times.

I must have missed what news you have about it.

Michel.



Vesna Manojlovic

2019-10-07 10:56:57 CET

RIPE NCC staff member

Hi all,

On 05/10/2019 15:05, Lee Howard wrote:
>> that said, we need more running code, still, which only then can
>> get into a deployment, and nobody's funding that.
>
> Do you mean CeroWRT specifically, or code in general?
>
> I was thinking about some Hackathon projects to add IPv6 capability to
> open source projects.
here are the results of the IPv6-themed hackathon we did 2 years ago:

https://labs.ripe.net/Members/becha/results-hackathon-version-6

One of the projects have added some IPv6 capability to PCAP tools
(libpcap) ...

)

Regards,
Vesna Manojlovic
Community Builder
RIPE NCC



Kai 'wusel' Siering

2019-10-07 12:33:33 CET

Am 07.10.19 um 06:07 schrieb Michel Py:
>> Kai 'wusel' Siering
>> Rationale: an internal network needing more than 16 million IPv4 addresses (10/8) does have the power to solve their
>> addressing needs with IPv6. This isn't true for newcomers that have to deal with old players not enabling v6.
> I do not agree because it does not fit my use-case, but this is the best argument I have heard for many years.
>
> Keep in mind though : your idea is great, but it has been tried many times, for more than a decade, including by people who are respected players, big shots, and have serious clout, and it has repeatedly failed. What makes you think that you can make it work ? Everyone has tried, everyone has failed. Multiple times.

What exactly are you asking about? Un-reserving 240/4 in general, or adding it to the public space instead of wasting just more precious v4 space on intranets? First, and again, I do not aim to 'liberate' 240/4, 0/8 or 127/8. From my perspective IPv4 entered the stage 30+ years ago and is now on it's farewell tour — which will take some more decades, until it finally becomes irrelevant in the DFZ. Any changes to it, like changing 240/4's status, is robbing a dead body. But _if_ people are considering to do this, to me public unicast is the only valid option. Again, if you need more that 16 million IPs for your intranet, IPv6 is your answer. I understand you dislike that, fine by me; so go and grab unannounced public space, just be prepared for renumbering. A quarter of 44/8 is already in active use by AWS, more of that will happen: The Clouds need unprecedented amounts of v4 space.

I have no doubt the RIR system will again fail to protect the newcomers, but raising my voice is the only thing I can do. I'm not a LIR, ATM I don't represent a LIR — and even if, as you already said, it's the money that decides. Which means: 240/8 e. g. needs to go to and used by AWS, 241/8 to GCP, 242/8 to CF; that should give lazy eyeball ISPs a reason to fix their v4 gear, and I think 6 months from an IANA announcement of 240/4 becoming public unicast to the first allocating is plenty of time for those involved. Would that fix end-to-end globally? No. Does it matter? Not really. ISP<>Cloud/CDN is what matters today; the rest will follow, taking the scenic route.

> I must have missed what news you have about it.

You have missed my point completely – see the "please note" in my post –, presumably as it doesn't fit your point of view. I also have "enough" v4 space for the forseeable future for my use case; I came early to the party, and covered my needs. Unlike you, though, I still do look out of my swampy pool and ponder about how things _should_ be, in that tiny dinosaur brain of mine ;)
-kai



Mikael Abrahamsson

2019-10-07 12:44:48 CET

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 _at_ swm.pp _dot_ se



Gert Doering

2019-10-07 12:56:20 CET

Hi,

On Mon, Oct 07, 2019 at 12:33:33PM +0200, Kai 'wusel' Siering wrote:
> I have no doubt the RIR system will again fail to protect the newcomers,

I take a bit of offense here.  We did what we could to "protect the
newcomers" with the "last /22" policy, but "gone is gone" - there just is
not enough v4, what else could we have done?

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


Nick Hilliard

2019-10-07 13:19:21 CET

Gert Doering wrote on 07/10/2019 11:56:
> I take a bit of offense here.  We did what we could to "protect the
> newcomers" with the "last /22" policy, but "gone is gone" - there just is
> not enough v4, what else could we have done?

No need to take offense - it's normal for our species to want to assign
blame when we're upset, and even more normal to want to fling poo at
other people to show how upset we are.

It's not as if ipv4 exhaustion snuck up on everyone unnoticed.  If
people don't like how things were handled, then why they didn't pipe up
with their suggestions while the problem was being discussed any time
over the last 25 years?  It seems a bit odd to start complaining at the
point that the registries were scraping the last bits of address space
from the bottom of the barrel.

Nick



Job Snijders

2019-10-07 13:21:40 CET

Perhaps Kai referred to the RIR system as a whole, not RIPE specifically.
If a /4 goes to the RIRs that would be a perspective we’d need to consider
on a global scale.

On Mon, Oct 7, 2019 at 20:19 Nick Hilliard <nick _at_ foobar _dot_ org> wrote:

> Gert Doering wrote on 07/10/2019 11:56:
> > I take a bit of offense here.  We did what we could to "protect the
> > newcomers" with the "last /22" policy, but "gone is gone" - there just is
> > not enough v4, what else could we have done?
>
> No need to take offense - it's normal for our species to want to assign
> blame when we're upset, and even more normal to want to fling poo at
> other people to show how upset we are.
>
> It's not as if ipv4 exhaustion snuck up on everyone unnoticed.  If
> people don't like how things were handled, then why they didn't pipe up
> with their suggestions while the problem was being discussed any time
> over the last 25 years?  It seems a bit odd to start complaining at the
> point that the registries were scraping the last bits of address space
> from the bottom of the barrel.
>
> Nick
>
>


Kai 'wusel' Siering

2019-10-07 13:23:53 CET

Moin,

on 07.10.19 12:56, Gert Doering wrote:
> I take a bit of offense here.

That's sad, and unintended; but that topic is totally OT here, as it is v4-only and about 1992-20something.
-kai



Kai 'wusel' Siering

2019-10-07 13:28:07 CET

On 07.10.19 13:21, Job Snijders wrote:
> Perhaps Kai referred to the RIR system as a whole

I did. "the RIR system" does not mean "only RIPE".
-kai



2019-10-07 13:41:23 CET

We can surely pack up and go home after scraping up a /4. And we can even give it tactically to critical content delivery so people will be forced to move on it.
As we speak the mobile industry is discussing IMSI depletion as it gears up to connect billion(s) of new gadgets to 5G.
This is not a v4 vs v6 war, it’s v4 and v6. If anything, v6 should be focusing and doubling down on the new uses coming along and not freting about IT managers of broken intranets.

> On 7 Oct 2019, at 11:33, Kai 'wusel' Siering <wusel+ml _at_ uu _dot_ org> wrote:
>
> Am 07.10.19 um 06:07 schrieb Michel Py:
>>> Kai 'wusel' Siering
>>> Rationale: an internal network needing more than 16 million IPv4 addresses (10/8) does have the power to solve their
>>> addressing needs with IPv6. This isn't true for newcomers that have to deal with old players not enabling v6.
>> I do not agree because it does not fit my use-case, but this is the best argument I have heard for many years.
>>
>> Keep in mind though : your idea is great, but it has been tried many times, for more than a decade, including by people who are respected players, big shots, and have serious clout, and it has repeatedly failed. What makes you think that you can make it work ? Everyone has tried, everyone has failed. Multiple times.
>
> What exactly are you asking about? Un-reserving 240/4 in general, or adding it to the public space instead of wasting just more precious v4 space on intranets? First, and again, I do not aim to 'liberate' 240/4, 0/8 or 127/8. From my perspective IPv4 entered the stage 30+ years ago and is now on it's farewell tour — which will take some more decades, until it finally becomes irrelevant in the DFZ. Any changes to it, like changing 240/4's status, is robbing a dead body. But _if_ people are considering to do this, to me public unicast is the only valid option. Again, if you need more that 16 million IPs for your intranet, IPv6 is your answer. I understand you dislike that, fine by me; so go and grab unannounced public space, just be prepared for renumbering. A quarter of 44/8 is already in active use by AWS, more of that will happen: The Clouds need unprecedented amounts of v4 space.
>
> I have no doubt the RIR system will again fail to protect the newcomers, but raising my voice is the only thing I can do. I'm not a LIR, ATM I don't represent a LIR — and even if, as you already said, it's the money that decides. Which means: 240/8 e. g. needs to go to and used by AWS, 241/8 to GCP, 242/8 to CF; that should give lazy eyeball ISPs a reason to fix their v4 gear, and I think 6 months from an IANA announcement of 240/4 becoming public unicast to the first allocating is plenty of time for those involved. Would that fix end-to-end globally? No. Does it matter? Not really. ISP<>Cloud/CDN is what matters today; the rest will follow, taking the scenic route.
>
>> I must have missed what news you have about it.
>
> You have missed my point completely – see the "please note" in my post –, presumably as it doesn't fit your point of view. I also have "enough" v4 space for the forseeable future for my use case; I came early to the party, and covered my needs. Unlike you, though, I still do look out of my swampy pool and ponder about how things _should_ be, in that tiny dinosaur brain of mine ;)
> -kai
>
>
>



Nick Hilliard

2019-10-07 14:12:34 CET

Kai 'wusel' Siering wrote on 07/10/2019 12:28:
> On 07.10.19 13:21, Job Snijders wrote:
>> Perhaps Kai referred to the RIR system as a whole
>
> I did. "the RIR system" does not mean "only RIPE".

spreading the blame out doesn't change much.  The problem of ipv4
exhaustion has been under discussion since the early 1990s, and that
discussion encompassed the role of the RIRs as a whole, 240/4, ipv6, the
role of fairness in ip addressing policies and lots more besides.

You're welcome to propose that large cdns be assigned 240/4, although I
wonder about the optics and wisdom of handing out this address space
exclusively to the large players, and politely declining everyone else.

Nick



Bjoern Buerger

2019-10-07 15:46:06 CET

* Gert Doering (gert _at_ space _dot_ net) [191007 12:56]:
> I take a bit of offense here.  We did what we could to "protect the
> newcomers" with the "last /22" policy, but "gone is gone" - there just is
> not enough v4, what else could we have done?

Let me answer this from the newcomer's side:
You did good and the policy is fine as it is.

Some of us just adapted and implemented IPv6 rightaway,
taking those breadcrumbs of v4 as fallback, while the
dinosaurs kept whining about missing IPv6 support for their
outdated windows 95 machines (which could be funny, if
it wasn't so pathetic). We did this despite the fact that
the old economy will use it's legacy ressources to
keep us out of the business and those who couldn't afford
to wait for the dinosaurs to die out are using lots of
cash to ease their pain.

Most newcomers COULD easily go v6-only and although there would be
problems, they would be able to handle that while moving forward.
That is ... IF those dinosaurs would move just a tiny bit and
at least implemented a minimum of IPv6 on their public services
and at least application proxies or nat64 for the rest of their
cruft.

But it's the same story as with climate change: The next generation
doesn't have a voice in this game, but will pay for the greed of
those who where lucky enough to be there for a long time when
plenty of ressources where available and the same legacy people
are now whining about the cost of change.

Bjørn



Bjoern Buerger

2019-10-07 15:57:43 CET

* Mikael Abrahamsson (swmike _at_ swm.pp _dot_ se) [191007 12:45]:
> On Android/iOS I'd say it's production ready.

Yes.

> On classic desktop OSes like MacOS, Windows and Linux it's not.
> The difference is the presence of widely available 464XLAT support.

>From my observation, that's correct.

Theoretically, there may be better solutions, but 464XLAT
ist just fine and does the job.

Bjørn



Dave Taht

2019-10-07 18:04:12 CET

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



Job Snijders

2019-10-07 18:16:38 CET

Dear Dave,

On Mon, Oct 7, 2019 at 4:04 PM Dave Taht <dave.taht _at_ gmail _dot_ 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

That may be how you measure success yourself, however I measure
valuable, regardless of the coffee shop's connectivity.

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.

Kind regards,

Job



bob.sleigh@bt.com

2019-10-07 18:27:00 CET

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 _at_ ripe _dot_ net> On Behalf Of Dave Taht
Sent: 07 October 2019 17:04
To: Bjoern Buerger <b.buerger _at_ penguin _dot_ de>
Cc: ipv6-wg _at_ ripe _dot_ net IPv6 <ipv6-wg _at_ ripe _dot_ 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

2019-10-07 18:36:27 CET

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 _at_ bt _dot_ 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 _at_ ripe _dot_ net> On Behalf Of Dave Taht
> Sent: 07 October 2019 17:04
> To: Bjoern Buerger <b.buerger _at_ penguin _dot_ de>
> Cc: ipv6-wg _at_ ripe _dot_ net IPv6 <ipv6-wg _at_ ripe _dot_ 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



Dave Taht

2019-10-07 18:37:04 CET

On Mon, Oct 7, 2019 at 9:23 AM <bob.sleigh _at_ bt _dot_ com> wrote:
>
> Congratulations on your contribution to success Dave!
>
> Regards
>
> Bob
>
> Sent from my local coffee shop - using my EE Mobile over native IPv6

Yea! thank you! That cheers me up a lot. I hadn't found a single coffee shop yet
that had it. But my request was that someone go to their local coffee
shop and *make* it work when it didn't

Care to go for 2/2? Test for bufferbloat via dslreports.com and/or
flent's rrul test?

> -----Original Message-----
> From: ipv6-wg <ipv6-wg-bounces _at_ ripe _dot_ net> On Behalf Of Dave Taht
> Sent: 07 October 2019 17:04
> To: Bjoern Buerger <b.buerger _at_ penguin _dot_ de>
> Cc: ipv6-wg _at_ ripe _dot_ net IPv6 <ipv6-wg _at_ ripe _dot_ 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.
>

--

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



bob.sleigh@bt.com

2019-10-07 19:10:11 CET

Hi Enno

Regards

Bob

-----Original Message-----
From: Enno Rey <erey _at_ ernw _dot_ de>
Sent: 07 October 2019 17:36
To: Sleigh,R,Bob,VQI R <bob.sleigh _at_ bt _dot_ com>
Cc: dave.taht _at_ gmail _dot_ com; b.buerger _at_ penguin _dot_ de; ipv6-wg _at_ ripe _dot_ net
Subject: Re: [ipv6-wg] Have we failed as IPv6 Working Group?

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 _at_ bt _dot_ 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 _at_ ripe _dot_ net> On Behalf Of Dave Taht
> Sent: 07 October 2019 17:04
> To: Bjoern Buerger <b.buerger _at_ penguin _dot_ de>
> Cc: ipv6-wg _at_ ripe _dot_ net IPv6 <ipv6-wg _at_ ripe _dot_ 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



Martin Schröder

2019-10-07 19:12:37 CET

Am Mo., 7. Okt. 2019 um 18:04 Uhr schrieb Dave Taht <dave.taht _at_ gmail _dot_ 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



Dave Taht

2019-10-07 19:16:43 CET

On Mon, Oct 7, 2019 at 9:16 AM Job Snijders <job _at_ instituut _dot_ net> wrote:
>
> Dear Dave,
>
> On Mon, Oct 7, 2019 at 4:04 PM Dave Taht <dave.taht _at_ gmail _dot_ 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
>
> That may be how you measure success yourself, however I measure
> 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:

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
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
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.sleigh@bt.com

2019-10-07 19:31:13 CET

Fair enough Dave, I can't fix any of that - but this thread is so despondent, I just hoped to make a few people smile!

There are areas of IPv6 success and I consider my (small) participation a few years ago to getting the UK's biggest mobile network onto native IPv6 one of those successes

Regards

Bob

-----Original Message-----
From: Dave Taht <dave.taht _at_ gmail _dot_ com>
Sent: 07 October 2019 17:37
To: Sleigh,R,Bob,VQI R <bob.sleigh _at_ bt _dot_ com>
Cc: Bjoern Buerger <b.buerger _at_ penguin _dot_ de>; ipv6-wg _at_ ripe _dot_ net IPv6 <ipv6-wg _at_ ripe _dot_ net>
Subject: Re: [ipv6-wg] Have we failed as IPv6 Working Group?

On Mon, Oct 7, 2019 at 9:23 AM <bob.sleigh _at_ bt _dot_ com> wrote:
>
> Congratulations on your contribution to success Dave!
>
> Regards
>
> Bob
>
> Sent from my local coffee shop - using my EE Mobile over native IPv6

Yea! thank you! That cheers me up a lot. I hadn't found a single coffee shop yet that had it. But my request was that someone go to their local coffee shop and *make* it work when it didn't already.

Care to go for 2/2? Test for bufferbloat via dslreports.com and/or flent's rrul test?

> -----Original Message-----
> From: ipv6-wg <ipv6-wg-bounces _at_ ripe _dot_ net> On Behalf Of Dave Taht
> Sent: 07 October 2019 17:04
> To: Bjoern Buerger <b.buerger _at_ penguin _dot_ de>
> Cc: ipv6-wg _at_ ripe _dot_ net IPv6 <ipv6-wg _at_ ripe _dot_ 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.
>

--

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


Dave Taht

2019-10-07 19:36:48 CET

On Mon, Oct 7, 2019 at 10:31 AM <bob.sleigh _at_ bt _dot_ com> wrote:
>
> Fair enough Dave, I can't fix any of that - but this thread is so despondent, I just hoped to make a few people smile!

At one level, now knowing my own ennui is shared so widely cheers me up.

"Pain shared, reduced, Joy shared, increased" - spider robinson

But after throwing a few glasses of grief in the fireplace, it would
be good to find ways of making constructive
progress forward.

> There are areas of IPv6 success and I consider my (small) participation a few years ago to getting the UK's biggest mobile network onto native IPv6 one of those successes
>
> Regards
>
> Bob
>
> -----Original Message-----
> From: Dave Taht <dave.taht _at_ gmail _dot_ com>
> Sent: 07 October 2019 17:37
> To: Sleigh,R,Bob,VQI R <bob.sleigh _at_ bt _dot_ com>
> Cc: Bjoern Buerger <b.buerger _at_ penguin _dot_ de>; ipv6-wg _at_ ripe _dot_ net IPv6 <ipv6-wg _at_ ripe _dot_ net>
> Subject: Re: [ipv6-wg] Have we failed as IPv6 Working Group?
>
> On Mon, Oct 7, 2019 at 9:23 AM <bob.sleigh _at_ bt _dot_ com> wrote:
> >
> > Congratulations on your contribution to success Dave!
> >
> > Regards
> >
> > Bob
> >
> > Sent from my local coffee shop - using my EE Mobile over native IPv6
>
> Yea! thank you! That cheers me up a lot. I hadn't found a single coffee shop yet that had it. But my request was that someone go to their local coffee shop and *make* it work when it didn't already.
>
> Care to go for 2/2? Test for bufferbloat via dslreports.com and/or flent's rrul test?
>
> > -----Original Message-----
> > From: ipv6-wg <ipv6-wg-bounces _at_ ripe _dot_ net> On Behalf Of Dave Taht
> > Sent: 07 October 2019 17:04
> > To: Bjoern Buerger <b.buerger _at_ penguin _dot_ de>
> > Cc: ipv6-wg _at_ ripe _dot_ net IPv6 <ipv6-wg _at_ ripe _dot_ 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.
> >
>
>
> --
>
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-205-9740

--

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



Bjoern Buerger

2019-10-07 20:05:18 CET

* Martin Schröder (martin _at_ oneiros _dot_ de) [191007 19:13]:
> Am Mo., 7. Okt. 2019 um 18:04 Uhr schrieb Dave Taht <dave.taht _at_ gmail _dot_ 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



Bjoern Buerger

2019-10-07 20:11:14 CET

* Dave Taht (dave.taht _at_ gmail _dot_ com) [191007 18:04]:
> 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

[done]  make Daves participation a success by helping local community
downstairs to be IPv6 enabled. Actually, did that multiple times,
not only with local coffeeshops. Also Hotels on the list.

I guess, that converts me into a certified IPv6 zealot.

[ ./. ] Bufferbloat .... well. This is the IPv6 working group. Maybe

Bjørn



Enno Rey

2019-10-07 20:11:41 CET

Hi,

On Mon, Oct 07, 2019 at 08:05:18PM +0200, Bjoern Buerger wrote:
> * Martin Schr?der (martin _at_ oneiros _dot_ de) [191007 19:13]:
> > Am Mo., 7. Okt. 2019 um 18:04 Uhr schrieb Dave Taht <dave.taht _at_ gmail _dot_ 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



2019-10-07 21:57:34 CET

Dave Taht <dave.taht _at_ gmail _dot_ 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

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 _at_ quux _dot_ de        | ---------------  |
----------------------------------------------------------------------------



Job Snijders

2019-10-08 05:29:59 CET

On Mon, Oct 07, 2019 at 08:11:41PM +0200, Enno Rey wrote:
> On Mon, Oct 07, 2019 at 08:05:18PM +0200, Bjoern Buerger wrote:
> > * Martin Schr?der (martin _at_ oneiros _dot_ de) [191007 19:13]:
> > > Am Mo., 7. Okt. 2019 um 18:04 Uhr schrieb Dave Taht <dave.taht _at_ gmail _dot_ 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
>
> slot in the wg in Rotterdam.  Let's identify who to talk to, from the
> meetings' NOC and other circles within RIPE NCC, beforehand.

If folks are serious about killing dual-stack ...

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

Perhaps the WG could RIPE NCC to register a domain like
ripe-ipv6-only-wg.org. This domain would have authoritative nameservers
only reachable via IPv6, an MTA that doesn't have any IPv4 connectivity
& a webserver with the charter, CoC, and mailing list archive only
accessible via IPv6. Much like how Marco David's dnslabs.nl is set up?

Kind regards,

Job



2019-10-08 07:28:05 CET

Dear WG, I apologise for coming late to the party, a long weekend to blame..

On Sun, Oct 6, 2019 at 10:53 AM Michel Py
<michel _at_ arneill-py.sacramento.ca _dot_ us> wrote:
> > If you want a war that is your choice, but please go and fight it somewhere else. RIPE
> > mailing lists are a place to be constructive and, as Job said, excellent to each other.
>
> Read the rest of my posts. I did not start the war. I did not start this thread.
> There are two ways to lose a war : lack of funds, and lack of courage. I have both.
>
> The war is global. Who do you think you are to tell me to take it somewhere else ?
> The chair of a mighty WG that has managed, in 20 years, to capture a whole 2.5% of the Internet traffic right in your own backyard at AMS-IX ?
>
> Kick me out of the mailing list, if you have the power to do so.

[with my co-chair hat on]

Michel,
I understand that you might be upset with the current state of
affairs. However I believe the whole discussion would be much more
productive
we we refrain from personal and/or provocative remarks.

Please be respectful to the WG participants, it would be highly appreciated.

Thank you.

--



Thomas Schäfer

2019-10-08 09:29:03 CET

You should know the difference between IPv6-only mailhosts and IPv6-only Wi-Fi + DNS64/NAT64.ThomasAm 08.10.2019 05:29 schrieb Job Snijders <job _at_ ntt _dot_ net>:On Mon, Oct 07, 2019 at 08:11:41PM +0200, Enno Rey wrote:
> On Mon, Oct 07, 2019 at 08:05:18PM +0200, Bjoern Buerger wrote:
> > * Martin Schr?der (martin _at_ oneiros _dot_ de) [191007 19:13]:
> > > Am Mo., 7. Okt. 2019 um 18:04 Uhr schrieb Dave Taht <dave.taht _at_ gmail _dot_ 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
>
> slot in the wg in Rotterdam.  Let's identify who to talk to, from the
> meetings' NOC and other circles within RIPE NCC, beforehand.

If folks are serious about killing dual-stack ...

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

Perhaps the WG could RIPE NCC to register a domain like
ripe-ipv6-only-wg.org. This domain would have authoritative nameservers
only reachable via IPv6, an MTA that doesn't have any IPv4 connectivity
& a webserver with the charter, CoC, and mailing list archive only
accessible via IPv6. Much like how Marco David's dnslabs.nl is set up?

Kind regards,

Job



Philip Homburg

2019-10-08 11:24:46 CET

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.



Bjoern Buerger

2019-10-08 12:17:50 CET

* Job Snijders (job _at_ ntt _dot_ net) [191008 05:37]:
> If folks are serious about killing dual-stack ...

Hmm, I would rephrase that to:

"If folks are serious about IPv6 and are willing to
set a real incentive for this community to have a
reality check and test their own infrastructure in
a safe environment with losts of experts around..."

Nobody wants to kill Dualstack right now. There will always
be a legacy network as backup, like on every other RIPE meeting.

But you won't see most of the common misconfigurations in a
Dualstack Environment and it's time to move out of your
comfort zone now.

Manually switching from default SSID to some legacy fallback
should not be a problem for those people with intentionally
old infrastructure. People who still run Windows 95 in 2019
will clearly have the expertise to klick on a button, right?

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

Bold move, but yes - why not?

By now, everybody with fairly recent infrastructure should have at least
Dualstack on their mailservers, so this shouldn't impose any problem,
right?

> Perhaps the WG could RIPE NCC to register a domain like
> ripe-ipv6-only-wg.org. This domain would have authoritative nameservers
> only reachable via IPv6, an MTA that doesn't have any IPv4 connectivity
> & a webserver with the charter, CoC, and mailing list archive only
> accessible via IPv6. Much like how Marco David's dnslabs.nl is set up?

Nice idea. You would have my support for this.

Bjørn



Rob Evans

2019-10-08 12:51:13 CET

> > 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



Geert Jan de Groot

2019-10-08 12:56:15 CET

Folks,

I've been out of the ISP business for a while now, but may I make some
observations:

Many of the major content providers are IPv6-enabled. The question is
for end users, how to use IPv6 to access these services.

In the Netherlands, there is no mobile operator providing IPv6
connectivity. None! I cannot get IPv6 on my mobile connection!

Also, in the Netherlands, the one Internet-to-home provider providing
dual-stack IPv6 (w/o NAT mess) is being assimilated by it's parent who,
after twenty-five years, is still technologically behind and can't
deliver IPv6 themselves.

The mitigation to get IPv6 access for endusers who can't get IPv6 from
their provider (sixxs.net) closed doors two year ago. I am not aware of
any VPN-provider offering IPv6 service to allow endusers to augment the
limited offering from their service provider.

It isn't a matter of "switch to a provider who has", for endusers, there
is *nothing to choose from*.

We can do all kinds of exercises (IPv6-only event networks,
eat-your-own-dogfood exercises), but there must be reasons for having a
business case for not providing IPv6 to end users. Perhaps they are
non-technical, but reasons they are; if there would be a business case,
people would be doing it.

And perhaps these (non-technical?) reasons should be something the WG
can look at. A fair number of members of this WG are related to the ISP
industry and perhaps can shine some light as to the "why don't you" for
access providers?

Geert Jan



Philip Homburg

2019-10-08 13:15:07 CET

In your letter dated Tue, 8 Oct 2019 12:56:15 +0200 you wrote:
>In the Netherlands, there is no mobile operator providing IPv6
>connectivity. None! I cannot get IPv6 on my mobile connection!

KPN announced last week (September 30) that they started providing
mobile customers with IPv6. They seem quite careful, so it may take a while
before they enable it everywhere.

>Also, in the Netherlands, the one Internet-to-home provider providing
>dual-stack IPv6 (w/o NAT mess) is being assimilated by it's parent who,
>after twenty-five years, is still technologically behind and can't
>deliver IPv6 themselves.

As far as I know, KPN does have some IPv6 on DSL. Both Ziggo and KPN
provide IPv6 with some sort of carrier grade NAT for IPv4. But it should be
easy enough to obtain real IPv4 elsewhere...



Eric Vyncke

2019-10-08 13:21:01 CET

At Brussels Midi station...

Did I win anything ?

[cid:image001.png@01D57DDB.312EFB10]

﻿On 07/10/2019, 18:04, "ipv6-wg on behalf of Dave Taht" <ipv6-wg-bounces _at_ ripe _dot_ net on behalf of dave.taht _at_ gmail _dot_ 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



Yannis Nikolopoulos

2019-10-08 14:07:32 CET


On 10/8/19 8:28 AM, Jen Linkova wrote:
> Dear WG, I apologise for coming late to the party, a long weekend to blame..
>
> On Sun, Oct 6, 2019 at 10:53 AM Michel Py
> <michel _at_ arneill-py.sacramento.ca _dot_ us> wrote:
>>> If you want a war that is your choice, but please go and fight it somewhere else. RIPE
>>> mailing lists are a place to be constructive and, as Job said, excellent to each other.
>>
>> Read the rest of my posts. I did not start the war. I did not start this thread.
>> There are two ways to lose a war : lack of funds, and lack of courage. I have both.
>>
>> The war is global. Who do you think you are to tell me to take it somewhere else ?
>> The chair of a mighty WG that has managed, in 20 years, to capture a whole 2.5% of the Internet traffic right in your own backyard at AMS-IX ?
>>
>> Kick me out of the mailing list, if you have the power to do so.
>
> [with my co-chair hat on]
>
> Michel,
> I understand that you might be upset with the current state of
> affairs. However I believe the whole discussion would be much more
> productive
> we we refrain from personal and/or provocative remarks.

*especially* provocative remarks. I haven't seen such toxicity in
anyone's messages in this list. This rhetoric is alien to this list (and
community I believe and hope). Please, take it some place where its
tolerated, not here

>
> Please be respectful to the WG participants, it would be highly appreciated.
>
> Thank you.
>



Andrew Yourtchenko

2019-10-08 15:09:10 CET


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 _at_ ripe _dot_ net> wrote:
>
> At Brussels Midi station...
>
> Did I win anything ?
>
> ﻿On 07/10/2019, 18:04, "ipv6-wg on behalf of Dave Taht" <ipv6-wg-bounces _at_ ripe _dot_ net on behalf of dave.taht _at_ gmail _dot_ 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
>
>


mailinglists@high5.alioth.uberspace.de

2019-10-08 16:57:59 CET

On 19-10-07 20:05:18, Bjoern Buerger wrote:
> * Martin Schr??der (martin _at_ oneiros _dot_ de) [191007 19:13]:
> > Am Mo., 7. Okt. 2019 um 18:04 Uhr schrieb Dave Taht <dave.taht _at_ gmail _dot_ 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
>
It is possible to do do v6 only networks;
troopers.de had a rather nice v6 only net and as a half pentest
conference included finding non working services as targets for the CTF.
Maybe you should just encourage power users to adopt v6 and annoy the
companies breaking it.
And maybe enno's name was mentioned somewhere there too... ;)

Greets
J



Petr Baudis

2019-10-08 16:59:58 CET

  Hi,

there have been many great points made from the perspective of "edge
/ leaf networks" and end-user connectivity.

An equally important is the serving side.  One aspect often discussed
are the availability of CDNs and major services.  But another aspect are
various SaaS and other non-infrastructure cloud deployments.

Since I did XS26 20 years ago, I now found myself managing a growing
set of cloud deployments on the SaaS side.  And IPv6 is definitely not
a first-class citizen, typically not configured by default, and often
actually just unsupported.

The current de-facto standard for modern deployments are Kubernetes
clusters.  And interestingly, I don't even have that clear an idea about
how well it supports IPv6 given how completely irrelevant to our daily
business life that is (even though I'm personally still subscribed e.g.
to this mailing list).

Apparently, K8s gained support for IPv6 just in the last year(!), but
currently you have choice just between IPv4-only and IPv6-only and work
on dualstack is still ongoing.  Meanwhile, Docker+Kubernetes is *the*
way to deploy cloud services everywhere right now, so that's a pretty
tell-tale signal.  And who knows what issues one will hit when at least
the basic infrastructure is finally in place and can be enabled easily
(or even becomes enabled by default).

the UX.  Just replacing IPv4 with IPv6 in the addresses listed in the
list of instances / pods / containers would have a huge influence on the
mindset of the developers, but this by itself will need to overcome
a huge friction.  Also, entirely new major UX improvements will likely
need to be developed, like having a DNS hostname autoconfiguration for
every cluster unit so that you don't need to actually work with IP
addresses manually anymore.  So it's just not about using DNS for the
having one for each of the 1000 pods you have deployed in your
microservice-oriented cluster in the cloud.

Just wanted to add this perspective, from the cloud side - both the
cloud providers, major cloud infrastructure frameworks and numerous
other services still have ways to go to (A) support IPv6 at all, (B)
support it without friction (esp. w/o endangering IPv4), (C) have
first-class UX for IPv6 otherwise the mindset of users will be still
IPv4-oriented.

Kind regards,

--
Petr Baudis, Rossum.ai
Creating a world without manual data entry



Wolfgang Zenker

2019-10-08 18:14:33 CET

* Job Snijders <job _at_ ntt _dot_ net> [191008 05:29]:
> On Mon, Oct 07, 2019 at 08:11:41PM +0200, Enno Rey wrote:
>> On Mon, Oct 07, 2019 at 08:05:18PM +0200, Bjoern Buerger wrote:
>>> * Martin Schr?der (martin _at_ oneiros _dot_ de) [191007 19:13]:
>>>> Am Mo., 7. Okt. 2019 um 18:04 Uhr schrieb Dave Taht <dave.taht _at_ gmail _dot_ 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

>> slot in the wg in Rotterdam.  Let's identify who to talk to, from the
>> meetings' NOC and other circles within RIPE NCC, beforehand.

> If folks are serious about killing dual-stack ...

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

> Perhaps the WG could RIPE NCC to register a domain like
> ripe-ipv6-only-wg.org. This domain would have authoritative nameservers
> only reachable via IPv6, an MTA that doesn't have any IPv4 connectivity
> & a webserver with the charter, CoC, and mailing list archive only
> accessible via IPv6. Much like how Marco David's dnslabs.nl is set up?

I think both suggested measures (going 100% ipv6-only on the meeting
network and on this mailing list) are a pretty bad idea. It might be
useful if we want to congratulate ourselfes how cool we are and how
good we can work in an IPv6-only environment, but it would have no use
whatsoever to help the RIPE community and the internet at large to
migrate towards a world where IPv6 is the "normal" protocol.

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.

Wolfgang
have,



Philip Homburg

2019-10-08 20:47:37 CET

>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?



Gert Doering

2019-10-08 22:58:40 CET

Hi,

On Tue, Oct 08, 2019 at 08:47:37PM +0200, Philip Homburg wrote:
> Considering those issues, why does it make sense to subject attendees of a
> RIPE meeting to such a network?

"Raise awareness" comes to mind...

Like "did your firewall vendor tell you that if you do VPN to your
dual-stacked firewall over IPv6, you will only be able to reach IPv6
hosts on the inside"?

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


Chriztoffer Hansen

2019-10-08 23:49:22 CET

Geert Jan de Groot,

Geert Jan de Groot wrote on 08/10/2019 12:56:
> In the Netherlands, there is no mobile operator providing IPv6
> connectivity. None!

That is technically _not_ true any-more.

KPN *very recently* - 9/30/2019 - published information they are going
to begin enabling v6 for mobile customers.[0][1][2][3]

--
Chriztoffer

[1]:
https://www.telecompaper.com/news/kpn-starts-moving-customers-to-ipv6--1310545
[2]:
[3]:
https://forum.kpn.com/mobiele-diensten-18/ipv6-voor-het-mobiele-netwerk-479605



Wolfgang Zenker

2019-10-09 03:27:09 CET

* Philip Homburg <pch-ripeml _at_ u-1.phicoh _dot_ 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

> 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



Thomas Schäfer

2019-10-09 10:41:03 CET

Am 08.10.19 um 18:14 schrieb Wolfgang Zenker:

> 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.

I would be a volunteer at ripe80, provided the DNS64/NAT64-Gateway isn't
overbooked.

That should be easy to ask 10 people.
(the other 890 will not have problems at all)

Do you want to investigate the problem?
Do you want just switch to the classic network?

Nobody will be without network and "we" would get an overview, where the
problems are.

Regards,
Thomas

--

There’s no place like ::1

Thomas Schäfer (Systemverwaltung)
Ludwig-Maximilians-Universität
Centrum für Informations- und Sprachverarbeitung
Oettingenstraße 67 Raum C109
80538 München ☎ +49/89/2180-9706  ℻ +49/89/2180-9701



Philip Homburg

2019-10-09 10:47:40 CET

>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.

A common complaint about IPv6 is that IPv6 is not just "IPv4 with longer
addresses", but made all kinds of changes that come back to bite us.
Another complaint is that there are almost always two ways of doing
something and sometimes many more.

So If we compare NAT64 on wifi with dual stack then we see both complaints
in action. Dual stack is perfectly compatible with IPv4-only devices.
In fact, it works so well that nobody even notices that they are connecting
to a dual stack network.

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. We cannot
use DNS64 if we expect IPv4 literals or local DNSSEC validation. 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.

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.



2019-10-09 11:16:14 CET

Philip Homburg <pch-ripeml _at_ u-1.phicoh _dot_ 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

If this would be deployed in the next 6 month many participants of RIPE 80 would use such a network.

Jens

--
----------------------------------------------------------------------------
| Delbrueckstr. 41    | 12051 Berlin, Germany           | +49-151-18721264 |
| http://blog.quux.de | jabber: jenslink _at_ quux _dot_ de        | ---------------  |
----------------------------------------------------------------------------



Sander Steffann

2019-10-09 17:06:09 CET

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



Sander Steffann

2019-10-09 17:08:25 CET

Hi,

> Geert Jan de Groot wrote on 08/10/2019 12:56:
>> In the Netherlands, there is no mobile operator providing IPv6 connectivity. None!
>
> That is technically _not_ true any-more.
>
> KPN *very recently* - 9/30/2019 - published information they are going to begin enabling v6 for mobile customers.[0][1][2][3]

Eagerly awaiting IPv6 on PDP_IP0 here :)
PDP_IP1 (which is used for VoLTE) is already IPv6-only.

Cheers,
Sander



Philip Homburg

2019-10-09 18:26:18 CET

>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.

>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 :)

There is an experimental NAT64 network. That should be enough for people
who love to fix something.

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.

>> 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...

I assumed that the point of testing this at a RIPE meeting is to deploy it
in other locations. In those locations, most people are not network engineers
but still have to deal with the fact that suddenly some devices/software
don't work on some wifi networks. And they have no clue why not, other than
that it has something to do with IPv6.

> 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?



2019-10-09 19:03:28 CET

Sander Steffann <sander _at_ steffann _dot_ nl> writes:

> 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 guess there will be quite a few devices were people disable IPv6.

>> 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 :)

And finding hosts in DNSSEC signed zones not supporting IPv6. I know at
least one.

Jens
--
----------------------------------------------------------------------------
| Delbrueckstr. 41    | 12051 Berlin, Germany           | +49-151-18721264 |
| http://blog.quux.de | jabber: jenslink _at_ quux _dot_ de        | ---------------  |
----------------------------------------------------------------------------



Gert Doering

2019-10-09 19:56:46 CET

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


Job Snijders

2019-10-10 03:06:16 CET

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

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
> > 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



2019-10-10 06:19:47 CET

On Thu, Oct 10, 2019 at 12:06 PM Job Snijders <job _at_ ntt _dot_ net> wrote:
> 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.

[skip]

> 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.

We do know why. The profile approach you suggested would work just
*slightly* better than two SSIDs.
Users do not care. They connect to the SSID their device remembered
and if there are multiple 'known' SSIDs nobody would pay attention to
which SSID
their device is connected to.

Imagine a WiFi network with a few thousands of users.
Step 1. Opt-in. You ask them to 'try IPv6-only' SSID - you must be
*very* lucky if you get more than 3-5% of users moving. Not because
smth does not work for them but because they are lazy.
Some of those who moved will be going back and forth between SSIDs w/o
even knowing it - here the 802.1x profile might help.
Step 2: Opt-out. You make the 'primary' SSID Ipv6-only and advise
those who are seeing issues to use another SSID. In that case I'd
expect to see between 70-85% of users stay on Ipv6-only (the number
does depend on mobile/laptop ratio on the network). For exactly the
same reason only 5% moves if you do opt-in: users are lazy and do not
care which SSID they connect to if it works.

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

> I maintain, let's first move this mailing list to an IPv6 only
> environment, if that is a success, perhaps we can reconsider.

I might be missing smth here: what does SMTP over IPv6 to do with the
ability of running an IPv6-only meeting WiFi network?

>If the
> argument is "but then the rest of the world can't talk to us"...
> exactly.

Oh then please clarify what exactly do you mean by 'moving the mailing
list to Ipv6-only environment'.
Running the mail server in an IPv6-only DC which has SIIT? *That* would work.
Removing all Ipv4 MXes/A? No it would not and the proper analogy would
be 'making the RIPE WiFi Ipv6-only w/o providing NAT64'.

--



Carlos Friacas

2019-10-10 09:34:57 CET

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



Thomas Schäfer

2019-10-10 09:53:29 CET

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



Gert Doering

2019-10-10 10:57:02 CET

Hi,

On Thu, Oct 10, 2019 at 09:53:29AM +0200, Thomas Schäfer wrote:
> By the way:  *single* SSID,
>
> What is the reason to provide
> "ripemtg" and "ripemtg-2.4-79"?

Somewhat wrong forum :-) - I think the issue was "band steering and funky
wifi drivers", and people could move their 2.4GHz-only-devices to this
SSID if they had problems in the dual-frequency SSID.

Not sure if this is still a thing.

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


2019-10-10 12:28:16 CET

On Thu, Oct 10, 2019 at 6:35 PM Carlos Friaças <cfriacas _at_ fccn _dot_ pt> 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)?

Corporate.

--



Bjoern Buerger

2019-10-10 23:56:12 CET

* Gert Doering (gert _at_ space _dot_ 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.

Bjørn



Philip Homburg

2019-10-11 09:30:55 CET

In your letter dated Thu, 10 Oct 2019 23:56:12 +0200 you wrote:
>* Gert Doering (gert _at_ space _dot_ 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.



Andrew Yourtchenko

2019-10-11 11:44:33 CET

*knock knock* is this mic on ?

Once upon a time during the FOSDEM post-conference gathering with organizers I challenged the notion that the dual stack was the state of the art. The organizers, being themselves in various tech roles, agreed. It was interesting to get to those days bleeding edge. Of course with NAT64.

Thus FOSDEM became the very first large-ish (above 5K clients) WiFi setups in the world to go with IPv6-only+NAT64 in the default SSID. The announcement was made during the opening session, which everyone attended.

We maybe had 20% clients remaining on the default “bleeding edge”. Which is a testament to the immense power of human laziness aka the law of the default: it was several hundred times more compared to the previous year when they SSID was “on the side”.

Mind you, this was the time when Android still wasn’t able to connect to IPv6 only on WiFi, and when iOS was flapping WiFi every minute, if connected to v6-only access. That time is long gone - every subsequent year the %% participation on the default IPv6-only access SSID nearly doubled.

Were there complaints ? In single digits, sure. (And about complaints in general: no temperature in the room can help avoid having complaints about it being too cold or too hot. Some of those complaints came from dual stack SSID and general confusion that happened first year) - if there is anyone from rest of the FOSDEM network crew of those years reading this, please correct me if I am missing anything.

But the overall feedback from the participants was overwhelmingly positive. And there was a lot of bug reports, questions, etc. directed at makers and vendors that didn’t support IPv6.

Since then it’s business as usual and no one is even asking.

So, IPv6-only access with NAT64 was a good thing to do for a technology-focused gathering of people.

For an unrelated business-focused gathering that would not have been a useful idea.

RIPE and IETF (and the vendor conferences for that matter) - being the mix of the two, are tricky to decide.

To me it all depends on an answer to a simple question: “do we want to lead the trends or do we want to follow them, and which ones ?” NB: both are valid business strategies.

What you care about with an IPv6 only access network at a short event is not necessarily just testing the apps. You care about the lasting memory and perception of that event that will be projected outward. It stopped being purely technical several years ago.

I hear “but there are non-technical people who just wanna get their job done”. Ironically from my experience they are the least ones to have problems, because they don’t use fancy outdated VPNs. And even if they do - they are empathetic enough to understand the modern 20-year technology still has kinks to iron, and smart enough to switch over to “-fallback” SSID or similar. Would you not be in their position ? If no, I am sorry for you. If yes - why would you think of them as lesser capable humans?

I hear “but if people experience problems with IPv6, it gives it a bad rap”. To which I reply - the opposite of love is not hate, its irrelevance and  indifference. Make it the best possible experience and let the glitches drive the improvement. This is the same way everywhere - business, relationships, knowledge.

I hear “but dualstack works fine”. Sure, but for a 4-day long event so does, from a layman’s practical standpoint, pure IPv4-only. Those in dire need of 128-bit address can use their corp VPN or - if they don’t have it - Cloudflare’s Warp+.  The latter works beautifully over any legacy - and accelerates the web experience too! [shoutout to Mahtin. Thank you so much!]

When I look at today’s application architectures and latest trends, I see a lot of parallels between today’s IPv4 Internet and PSTN from 30 years ago. It’s fascinating to imagine how it all looks in 30 years from now, in another perspective, when it inevitably changes again.

Provided that whole climate thing still allows us to hang around :-)

Thanks for listening if you made it till here.

Sometimes I wish I could make a sequel to my now probably biggest career contribution (“NATs are good” video), but ironically that startup is no more, they got bought, and it’s all now a serious business, no kidding.

—a

> On 11 Oct 2019, at 09:30, Philip Homburg <pch-ripeml _at_ u-1.phicoh _dot_ com> wrote:
>
> In your letter dated Thu, 10 Oct 2019 23:56:12 +0200 you wrote:
>> * Gert Doering (gert _at_ space _dot_ 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.
>
>
>



Bjoern Buerger

2019-10-11 12:03:23 CET

* Philip Homburg (pch-ripeml _at_ u-1.phicoh _dot_ 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



Philip Homburg

2019-10-11 13:46:16 CET

>> 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

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?

The cisco report on FOSDEM 2019 has an interesting statistic:
"There were more clients on the IPv6 native network then on the IPv4 network,
"with on Sunday afternoon ~3330 IPv4 DHCP clients against ~4300 reachable
"IPv6-only clients and ~1300 IPv6 clients on the dual stack network.

That suggests that 3330 'clients' picked the non-default dual stack network
compared to 4300 'clients' that used the default SSID.



Gert Doering

2019-10-11 14:03:53 CET

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