Michel Py <michel(a)arneill-py.sacramento.ca.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(a)taht.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
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.
> 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 :
> https://www.internetgovernance.org/2019/02/20/report-on-ipv6-get-ready-for-…
> And the full text :
> https://www.internetgovernance.org/wp-content/uploads/IPv6-Migration-Study-…
> 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
Earlier in this thread I'd asked: "How is ipv6 going to work over 5G"?
and got no replies. Anyone? All I know is the
3gpp working groups have been participating in ietf a bit, and we're
"in a race" to 5G, currently controversial due to
huewei being so far ahead on it than everyone else and controlled by
the chinese PLA.
My primary interest is in the fixed line deployments of the wireless
stuff that can only work outdoors - not the phones.
I know of multiple providers planning to replace dsl with 5G but have
no idea how they plan to do it. I figure CGNAT factors in a lot.
Are people going to get a /48? Static or dynamic?
How will ipv4 be delivered?
Can they buy a real IPv4 address for their business?
Any pointers to public documents on how it's intended to work with
ipv6 would be welcomed, and if this is a question
covered by this group before, please steer me in the right directions.
thx.
--
Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740
On Mon, Oct 7, 2019 at 9:23 AM <bob.sleigh(a)bt.com> wrote:
>
> Congratulations on your contribution to success Dave!
>
> Regards
>
> Bob
>
> Sent from my local coffee shop - using my EE Mobile over native IPv6
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(a)ripe.net> On Behalf Of Dave Taht
> Sent: 07 October 2019 17:04
> To: Bjoern Buerger <b.buerger(a)penguin.de>
> Cc: ipv6-wg(a)ripe.net IPv6 <ipv6-wg(a)ripe.net>
> Subject: Re: [ipv6-wg] Have we failed as IPv6 Working Group?
>
> If I can get *one* person in this working group to go down to their local coffee shop and make ipv6 work by whatever means necessary (and also fix their bufferbloat) - I'll consider my participation in this thread a success.
>
--
Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740
On 10/5/19 12:06 PM, Dave Taht wrote:
> Lee Howard <lee(a)asgard.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), 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.
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
On 10/5/19 11:53 AM, Dave Taht wrote:
> Lee Howard <lee(a)asgard.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
Hi Raymond,
You have my support for another round.
Erik Bais
From: ipv6-wg <ipv6-wg-bounces(a)ripe.net> on behalf of "raymond.jetten(a)elisa.fi" <raymond.jetten(a)elisa.fi>
Date: Friday 13 September 2019 at 12:04
To: RIPE IPv6 WG <ipv6-wg(a)ripe.net>
Cc: "ipv6-wg-chairs(a)ripe.net" <ipv6-wg-chairs(a)ripe.net>
Subject: [ipv6-wg] IPv6 WG co-chair selection
Hello again,
Apologies for the previously incomplete and spelling mistakes email.
I hope below is a better version :
--
Hello All,
Its almost 3 years ago that I started as a IPv6-WG co-chair, so as per our current policy it's time to step down.
However, I’m very willing to stand for re-selection, and serve another term as IPv6 WG co-chair, which I hope you all find a good idea.
The full process is described here:
https://www.ripe.net/participate/ripe/wg/ipv6/ipv6-wg-chair-selection-proce…
See you all in Rotterdam!
Rgds,
Ray
Uros Gaber <uros(a)gaber.in> writes:
> On 3 Oct 2019, at 14:03, Job Snijders <job(a)instituut.net> wrote:
>> Even worse, delivering email over ipv6 to the mail giants is a far
>> worse experience than via ipv4. More emails arrive when you
>> disable ipv6 on your mail servers.
> I would say the same experience as long as the server and supported
> services are configured correctly.
If you google correctly you'll find many people compiling about google
not accepting mail via IPv6. Therefore not many people do SMTP via
IPv6. Or if they do they have an extra (v4 only) transport in their
outgoing SMTP server. ==> Runing Dualstack is more work.
Jens
--
----------------------------------------------------------------------------
| Delbrueckstr. 41 | 12051 Berlin, Germany | +49-151-18721264 |
| http://blog.quux.de | jabber: jenslink(a)quux.de | --------------- |
----------------------------------------------------------------------------
+1 support for Ray
Regards,
James
From: ipv6-wg [mailto:ipv6-wg-bounces@ripe.net] On Behalf Of Jetten Raymond
Sent: 13 September 2019 12:04
To: RIPE IPv6 WG <ipv6-wg(a)ripe.net>
Cc: ipv6-wg-chairs(a)ripe.net
Subject: [ipv6-wg] IPv6 WG co-chair selection
Hello again,
Apologies for the previously incomplete and spelling mistakes email.
I hope below is a better version :
--
Hello All,
Its almost 3 years ago that I started as a IPv6-WG co-chair, so as per our current policy it's time to step down.
However, I'm very willing to stand for re-selection, and serve another term as IPv6 WG co-chair, which I hope you all find a good idea.
The full process is described here:
https://www.ripe.net/participate/ripe/wg/ipv6/ipv6-wg-chair-selection-proce…
See you all in Rotterdam!
Rgds,
Ray
