The true enemy here is mid-level management that refuses to prioritize deployment of IPv6.
What we should be discussing is how best to approach that problem. It's where ops and corporate politics overlap.
How about just doing it and then asking for forgiveness later :-)?
That's what I did in 2005, but fair point, the network was only 2 routers big and in just one city :-).
Mark.
I would be looking for a new job and it is a much larger network than 2 routers is a big city. 
Sabri Berisha was correct: "The true enemy here is mid-level management that refuses to prioritize deployment of IPv6. What we should be discussing is how best to approach that problem. It's where ops and corporate politics overlap." What I always heard when I bring it up and they don't want to talk about it was "What's the business case?" They know there isn't one.
scott
Apologies for the top-post to a bottom-thread; I blame Outlook.
I was going to comment that in a couple of corporate network engineering roles I've had, the lack of the business case has always been to highlight that all the things we want to reach on the Internet can be accessed by IPv4.
So the business case will be the 'killer app' or perhaps 'killer service' that's IPv6-only and that'll provide a business reason.
But chicken and egg.. who wants to run a service that's IPv6-only and miss out on such a big userbase?
What remains is sliding IPv6 in as a minimal-cost service upgrade when you lifecycle your equipment. And when it's not minimal-cost (due to perhaps, complex firewall/nat arrangements), it's still a hard ask.
I don't have the answer to this yet, but occasionally a tech-savvy executive buys-in on the need to future-proof things.
Mark.
You've just answered yourself, which is the sad (but true) reality.
It will always come down to numbers, especially if you need to expend money on kit or use limited human resources that are already tied up with money-making projects.
If you can show that further delaying IPv6 deployment will have a direct impact on loss of revenue (particularly in the immediate), then you'll have a better chance of getting the deployment approved. The problem is any relationship between IPv6 and the going concern of the business is most likely to be indirect, which will make your task even that much harder.
Perhaps appealing to your management's sense of "something else", that when combined with (loss of) revenue, gives them a minute to pause and think. I wouldn't know what that "something else" as it pertains to your specific business, but maybe you do.
Mark.
Perhaps it's time that we made good friends with the folk accelerating pr0n, and did a deal with them where someone's fetish was only available over IPv6. Small enough that it does not bother their existing cash cow, but large enough that it starts to get some notice, where eyeballs can put pressure on their service providers to get them access.
I'm not kidding. Because sitting back and hoping "things just happen" is kind of like throwing a switch into a building and putting the words "IXP" outside, and hoping the right people will come knocking. We know IXP's are obvious, but a lot of their growth comes from their operators running around and actually getting patronage going.
IPv6 is obvious. But I think it requires a lot more non-technical agency to get it adopted.
Mark.
Perhaps it's time that we made good friends with the folk accelerating
pr0n, and did a deal with them where someone's fetish was only
available over IPv6.
hint: that idea is from the late '90s. the next bright idea for what
would help ipv6 take over the internet was 3gpp. it's been a long line
of things which would make ipv6 take off. and at least ten million
messages on mailing lists such as this. and the adoption rate has
crawled up slowly; the first derivative remaining fairly flat.
of course, if you measure it at the right place, it can have steep
points. when goog tured it up for youtube, the proportion of their v6
traffic went up nicely; no surprise. but when i want to measure a real
rate of change, i like a mid-stream sample at some isps' borders or ixp,
away from eyeballs or eye candy.
if we all spent as much time deploying, or helping others deploy as
opposed to screaming at them that they must do it asap, we might get
that first derivative up a wee bit. but i fear that, at this point,
patience is what is most useful.
randy
Like I was saying to someone privately, by pr0n I really meant whatever app or service makes the most sense at the time. It could be gaming, it could be Clubhouse, it could a crossword puzzle. Something, anything. We know how to build online services that ordinary people see value in. Extending that to have it delivered mostly over IPv6 is not a huge leap, if all sides understood that the impetus was to promote IPv6 adoption.
But yes, short of that, patience is the only hope.
Mark.
Hi,
hint: that idea is from the late '90s. the next bright idea for what
would help ipv6 take over the internet was 3gpp. it's been a long line
of things which would make ipv6 take off.
You are 100% Correct. Perhaps we can get Jeff Bezos to give 25% extra off
at the next Cyber Monday event to those accessing amazon.com via IPv6.
That will not only drive IPv6 deployment at eyeball networks, it's a
feasible plan as well. IF good ol' Jeff wants to cooperate
Thanks,
Sabri
Dropping a few feet from cloud nine, there, really, is no other thing that will facilitate or hold back the adoption of IPv6, like money.
It will distill down into who is willing to spend it, make it or lose it.
All (other) discussions about IPv6's adoption (or lack thereof) are just recycled revolutions around this reality. I mean, there's a reason that in 2021, PS4 still does not support IPv6.
Mark.
Well actually, that's not entirely true. One thing holding back IPv6
is the unfortunately routine need to turn it off in order to get one
or another IPv4 thing back working again. Like the disney thing
earlier in this thread. Or like my experience yesterday where I had to
disable IPv6 to fetch files on a particular server because SLAAC was
serving up invalid addresses but the app insisted on trying all 8 IPv6
addresses before it would attempt any of the IPv4 addresses. And of
course I can't call my ISP and say: you're causing my Linux box to
pick up bad IPv6 addresses. Front line support can barely handle IPv4
and Windows.
I stuck with it for a couple hours and figured out how to disable
SLAAC without disabling DHCP-PD so that I could turn IPv6 back on with
addresses which worked. But really, how many people are going to do
that? Most tick the IPv6 checkbox to off and are done with it.
This particular problem could be quickly resolved if the OSes still
getting updates were updated to default name resolution to prioritize
the IPv4 addresses instead. That would allow broken IPv6
configurations to exist without breaking the user's entire Internet
experience. Which would allow them to leave it turned on so that it
resumes working when the error is eventually found and fixed.
Prioritizing IPv6 over IPv4 for newly initiated connections is one of
the trifecta of critical design errors that have been killing IPv6 for
two decades. One of the two that if key folks weren't being so
bull-headed about it, it would be trivial to fix.
Regards,
Bill Herrin
This is not unique to IPv6. Almost every protocol (including IPv4) has some inherent design problem that keeps lists like this alive with swaths of advice and solutions.
But at its core, if money is going to stand in the way of IPv6 gaining global interest, the issues you, me and others face with SLAAC and other technical IPv6 annoyances will never receive the attention they need to get resolved.
Why fix something nobody wants to use in the first place?
Mark.
Dropping a few feet from cloud nine, there, really, is no other thing
that will facilitate or hold back the adoption of IPv6, like money.Well actually, that's not entirely true. One thing holding back IPv6
is the unfortunately routine need to turn it off in order to get one
or another IPv4 thing back working again. Like the disney thing
earlier in this thread. Or like my experience yesterday where I had to
disable IPv6 to fetch files on a particular server because SLAAC was
serving up invalid addresses but the app insisted on trying all 8 IPv6
addresses before it would attempt any of the IPv4 addresses. And of
course I can't call my ISP and say: you're causing my Linux box to
pick up bad IPv6 addresses. Front line support can barely handle IPv4
and Windows.I stuck with it for a couple hours and figured out how to disable
SLAAC without disabling DHCP-PD so that I could turn IPv6 back on with
addresses which worked. But really, how many people are going to do
that? Most tick the IPv6 checkbox to off and are done with it.This particular problem could be quickly resolved if the OSes still
getting updates were updated to default name resolution to prioritize
the IPv4 addresses instead. That would allow broken IPv6
configurations to exist without breaking the user's entire Internet
experience. Which would allow them to leave it turned on so that it
resumes working when the error is eventually found and fixed.Prioritizing IPv6 over IPv4 for newly initiated connections is one of
the trifecta of critical design errors that have been killing IPv6 for
two decades. One of the two that if key folks weren't being so
bull-headed about it, it would be trivial to fix.
Complain to your vendors about not implementing RFC 8305, RFC 6724, and
RFC 7078. RFC 8305 or RFC6724 + RFC 7078 would fix your issue.
Thats Happy Eyeballs and tuneable address selection rules.
You don’t have to perform the naive connection from getaddrinfo() man page.
struct addrinfo hints, *res, *res0;
int error;
int s;
const char *cause = NULL;
memset(&hints, 0, sizeof(hints));
hints.ai_family = PF_UNSPEC;
hints.ai_socktype = SOCK_STREAM;
error = getaddrinfo("www.kame.net", "http", &hints, &res0);
if (error) {
errx(1, "%s", gai_strerror(error));
/*NOTREACHED*/
}
s = -1;
for (res = res0; res; res = res->ai_next) {
s = socket(res->ai_family, res->ai_socktype,
res->ai_protocol);
if (s < 0) {
cause = "socket";
continue;
}
if (connect(s, res->ai_addr, res->ai_addrlen) < 0) {
cause = "connect";
close(s);
s = -1;
continue;
}
break; /* okay we got one */
}
if (s < 0) {
err(1, "%s", cause);
/*NOTREACHED*/
}
freeaddrinfo(res0);
You could actually use something a little more sophisticated like
int
connect_to_host(struct addrinfo *res0) {
struct addrinfo *res;
int fd = -1, n, i, j, flags, count;
struct pollfd *fds;
int timeout = TIMEOUT;
/*
* Work out how many possible descriptors we could use.
*/
for (res = res0, count = 0; res; res = res->ai_next)
count++;
fds = calloc(count, sizeof(*fds));
if (fds == NULL) {
perror("calloc");
goto cleanup;
}
for (res = res0, i = 0, count = 0; res; res = res->ai_next) {
fd = socket(res->ai_family, res->ai_socktype, res->ai_protocol);
if (fd == -1) {
/*
* If AI_ADDRCONFIG is not supported we will get
* EAFNOSUPPORT returned. Behave as if the address
* was not there.
*/
if (errno != EAFNOSUPPORT)
perror("socket");
else if (res->ai_next != NULL)
continue;
} else if ((flags = fcntl(fd, F_GETFL)) == -1) {
perror("fcntl");
close(fd);
} else if (fcntl(fd, F_SETFL, flags | O_NONBLOCK) == -1) {
perror("fcntl");
close(fd);
} else if (connect(fd, res->ai_addr, res->ai_addrlen) == -1) {
if (errno != EINPROGRESS) {
perror("connect");
close(fd);
} else {
/*
* Record the information for this descriptor.
*/
fds[i].fd = fd;
fds[i].events = POLLERR | POLLHUP |
POLLIN | POLLOUT;
count++;
i++;
}
} else {
/*
* We connected without blocking.
*/
goto done;
}
if (count == 0)
continue;
do {
if (res->ai_next == NULL)
timeout = -1;
n = poll(fds, i, timeout);
if (n == 0) {
timeout >>= 1;
break;
}
if (n < 0) {
if (errno == EAGAIN || errno == EINTR)
continue;
perror("poll");
fd = -1;
goto done;
}
for (j = 0; j < i; j++) {
if (fds[j].fd == -1 || fds[j].events == 0 ||
fds[j].revents == 0)
continue;
fd = fds[j].fd;
if (fds[j].revents & POLLHUP) {
close(fd);
fds[j].fd = -1;
fds[j].events = 0;
count--;
continue;
}
/* Connect succeeded. */
goto done;
}
} while (timeout == -1 && count != 0);
}
/* We failed to connect. */
fd = -1;
done:
/* Close all other descriptors we have created. */
for (j = 0; j < i; j++)
if (fds[j].fd != fd && fds[j].fd != -1) {
close(fds[j].fd);
}
if (fd != -1) {
/* Restore default blocking behaviour. */
if ((flags = fcntl(fd, F_GETFL)) != -1) {
flags &= ~O_NONBLOCK;
if (fcntl(fd, F_SETFL, flags) == -1)
perror("fcntl");
} else
perror("fcntl");
}
cleanup:
/* Free everything. */
if (fds != NULL) free(fds);
return (fd);
}
Mark
Yet both ps5 and xbox series x have ipv6 support
A console released in 2013 do not, but its successor released in 2020 have it
How wild is this, I wonder why ?
Hi Mark,
When I said bull-headed, this is exactly what I had in mind. Happy
eyeballs and things like
Index of /freebies/libeasyv6-0.1 aren't first-class
citizens in the APIs. Their code has to be independently added to each
application individually. Getaddrinfo() is core standard. Fix the
problem in the place that fixes it in every place or else it's never
really fixed.
Regards,
Bill Herrin
IPv6 also runs on hardware that was shipped as far back as 2003, if not earlier.
Mark.
Mark -
You’ve properly pointed out IPv6 can indeed be readily & safely deployed today using modern equipment that supports a reasonable transition approach… full agreement there.
Interestingly enough, you’ve also pointed out the not-so-secret reason why it’s taken so long to get sizable deployment of IPv6 – that is, despite us knowing that we needed "a straightforward transition plan” on day one that documented how to move from IPv4 to IPng (aka IPv6), we opted in 1995 to select a next generation protocol which lacked any meaningful transition plan and instead left that nasty transition topic as an exercise for the reader and/or addressed by postulated outputs from newly-defined working groups… thus the underlying reason for the lost decades of creative engineering efforts in gap-filling by those who came after and had to actually build working networks and applications using IPv6.
For what it’s worth, I do think we’re finally 98 or 99% of the way there, but it has resulted some very real costs - rampant industry confusion, loss of standards credibility, etc. There’s some real lessons to be had here – as one who was in the IP Directorate at the time (and thus sharing in the blame), I know I would have done quite a bit differently, but it’s unclear if there’s been any systematic look-back or institutional learning coming out of the entire experience.
FYI,
/John
Oh, come on Bill. This ain't your first rodeo. You know damned well
that if we do that, the errors are in fact *not* eventually found and fixed.
In addition, if you do that, even once the error is fixed, the box will
not know about that and will continue to use the IPv4 addresses.
I don't know that and neither do you. That remains an untested theory.
What I do know, with the perfection of 20/20 hindsight, is that
v6-first has impeded deployment for two decades by routinely giving
folks a reason to turn IPv6 back off.
Hard headed.
Regards,
Bill Herrin
Actually John - IPng started out being called IPv7, but we caught the mistake and renamed it IPv6. Whew
Geoff