I've always found this argument to be confusing to me, at best - Realistically, you only need to know what network segment you're working in, so the first half of the address doesn't change at all.
And if you're using DHCPv6 and/or static addressing, well then.... prefix you already know, and the rest of the address is as short or long as you want it. Even so without that, it's still only half the address you need to know that differs. The 128-bit format is a wonder for handling things programmatically and design work as well, and isn't constrained to historical PDP-11 NIC/register limitations. "too many bits" has always been a "Can't understand breaking the address in half" kind of argument to me, and doing tricks like encoding VLAN IDs or site IDs (or both!) in addressing (first half) has been a godsend for troubleshooting and pinpointing where things are blindly. A lot of work I have done in the past 5 years or so has been reducing IPv4 on customer (not residential, though) networks, to reduce cost, complexity, and increase reliability, with just small edge translation points for V4 access. For software we develop and maintain, we've entirely removed NAT support/workarounds. Not worth maintaining. Tearing down my last STUN-type solution that was no longer needed by that last customer was a great thing - less code, less infrastructure, and just works without hacks. Network renumbering has been a breeze, too - if you've got privacy extensions off for internal infra (which, I would think, would be normal....) then an inventory of MAC addresses gets you right back to where you are, even though the second half of the address doesn't actually change, just the first half, and no endpoint host configuration work is needed in a proper setup. Hell, you can dual home and renumber over time/expiry instead of hard cuts, too! -----Original Message----- From: Jay Acuna via NANOG <[email protected]> Sent: Tuesday, June 16, 2026 5:31 PM To: North American Network Operators Group <[email protected]> Cc: Arie Vayner <[email protected]>; Jay Acuna <[email protected]> Subject: Re: IPv4 flag day On Tue, Jun 16, 2026 at 4:21 PM Arie Vayner via NANOG <[email protected]> wrote: >[...] In my view, this is a core reason why IPv6 adoption remains low >in the enterprise space: it requires fundamental paradigm shifts >rather than a simple protocol update. Yes. And there are many issues with running IPv6 systems. One of the major problems is there are way too many bits, and they've created addresses which simply cannot be typed (practically). It is as if the designers of the protocol didn't learn from IPv4 and did not care at all about basic needs of operators. One of those needs is the capability to look at a System logging console, and see an address which can be remembered for 5 seconds and typed into a terminal in 5 seconds. In order to troubleshoot or diag some issue. To identify and group traffic. To add or remove a single host from a blocklist. Copy and paste is not always available and not always suitable. Neither are DNS nor reverse DNS mappings. In a number of important ways IPv6 was fatally deficient. I believe a flag day is out of the question. Perhaps some day a suitable protocol would be devised to take the place of V6. > Thanks, > Arie -- -JA _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/WEPJRT6BJLH4ML7AYJKEANLMA2W4IQXM/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/UZRVANXRLMDZPRMXUDBKVKTBMAYLIQ3R/
