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. -----Original Message----- From: NANOG <nanog-bounces+blakjak=blakjak.net@nanog.org> On Behalf Of scott Sent: Sunday, 14 February 2021 1:01 pm To: nanog@nanog.org Subject: Re: DoD IP Space On 2/12/2021 8:39 PM, Mark Tinka wrote:

On 2/12/21 21:56, scott wrote:

...

100% agreed! Been whining about that here many times. I have been trying to get IPv6 going for a long time, but the above stopped my plans. One thing I mentioned recently, though, is we just got a $BIGCUSTOMER and their requirement was we do IPv6. So keep your IPv6 deployment plans ready. In my case they said a 'we need it right now' kind of thing. That could happen to anyone here.

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

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

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

----- On Feb 14, 2021, at 11:56 AM, Randy Bush randy@psg.com wrote: 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

On Sun, Feb 14, 2021 at 8:27 PM Mark Tinka <mark@tinka.africa> wrote:

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. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/

On 15 Feb 2021, at 17:25, William Herrin <bill@herrin.us> wrote:

On Sun, Feb 14, 2021 at 8:27 PM Mark Tinka <mark@tinka.africa> wrote:

...

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); } See https://users.isc.org/~marka/ Mark

Regards, Bill Herrin

-- William Herrin bill@herrin.us https://bill.herrin.us/

-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

On 15 Feb 2021, at 2:01 AM, Mark Andrews <marka@isc.org> wrote:

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

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

it’s unclear if there’s been any systematic look-back or institutional learning coming out of the entire experience.

i am always impressed by optimism in the face of cold reality

On Mon, Feb 15, 2021 at 7:49 AM Valdis Klētnieks <valdis.kletnieks@vt.edu> wrote:

On Sun, 14 Feb 2021 22:25:56 -0800, William Herrin said:

...

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.

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.

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 -- William Herrin bill@herrin.us https://bill.herrin.us/

On 2/15/21 09:59, nanog@jack.fr.eu.org wrote:

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 ?

IPv6 also runs on hardware that was shipped as far back as 2003, if not earlier. Mark.

I remember. And I have the HE.net Guru Badge to prove it :) And don’t forget the World IPv6 Launch in 2012. IPv6. The protocol of the future, and always will be :) -mel via cell

On Feb 26, 2021, at 3:49 PM, Jay Hennigan <jay@west.net> wrote:

On 2/13/21 18:24, Mark Foster wrote:

...

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?

Am I the only one who remembers "The Great IPv6 Experiment" from way back in 2007?

-- Jay Hennigan - jay@west.net Network Engineering - CCIE #7880 503 897-8550 - WB6RDV

On 2/14/21 02:00, scott wrote:

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.

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.