Exactly what I was asking, when and how will we collectively turn off the lights on IPv4?
-----Original Message----- From: NANOG <nanog-bounces+jacques.latour=cira.ca@nanog.org> On Behalf Of Mark Andrews Sent: March 30, 2022 7:29 PM To: NANOG <nanog@nanog.org> Subject: [EXT] Re: IPv6 Only - was Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC
Sites looking at the traffic they get and saying, you know what all our customers connect to us over IPv6 with some of them also connecting over IPv4. I think we can stop supporting IPv4 now.
ISP’s saying this IPv4aaS isn’t getting much traffic anymore lets out source it for the few customers that are still using it. Lots of ISPs are well down the path leading to this point by turning off IPv4 on the access networks.
Home / enterprise networks. All my gear is IPv6 capable and supports IPv4aaS for the few legacy IPv4 sites I need to connect to. This is happening today.
In the end almost all the IPv4 traffic with be with the third party IPv4aaS providers and collectively they will decide to turn off the lights.
On 30 Mar 2022, at 07:53, Jacques Latour <Jacques.Latour@cira.ca> wrote:
So, in 25, 50 or 100 years from now, are we still going to be dual stack IPv4/IPv6? When are we going to give up on IPv4? People can run IPv4 all they want inside their networks for 1000s of years. What will it take to be IPv6 only?
😊
From: NANOG <nanog-bounces+jacques.latour=cira.ca@nanog.org> On Behalf Of Owen DeLong via NANOG Sent: March 29, 2022 3:52 PM To: Abraham Y. Chen <aychen@avinta.com> Cc: NANOG <nanog@nanog.org> Subject: [EXT] Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC
Submit an Internet draft, same as any other IP related enhancement gets introduced.
What you’re really complaining about is that it’s been virtually impossible to gain consensus to move anything IPv4 related forward in the IETF since at least 2015.
Well… It’s a consensus process. If your idea isn’t getting consensus, then perhaps it’s simply that the group you are seeking consensus from doesn’t like your idea.
Your inability to convince the members of the various working groups that your idea has merit isn’t necessarily a defect in the IETF process… It might simply be a lack of merit in your ideas.
Owen
On Mar 26, 2022, at 15:43 , Abraham Y. Chen <aychen@avinta.com> wrote:
Hi, Justin:
1) "... no one is stopping anyone from working on IPv4 ... ": After all these discussions, are you still denying this basic issue? For example, there has not been any straightforward way to introduce IPv4 enhancement ideas to IETF since at least 2015. If you know the way, please make it public. I am sure that many are eager to learn about it. Thanks.
Regards,
Abe (2022-03-26 18:42)
On 2022-03-26 11:20, Justin Streiner wrote: While the Internet is intended to allow the free exchange of information, the means of getting that information from place to place is and has to be defined by protocols that are implemented in a consistent manner (see: BGP, among many other examples). It's important to separate the ideas from the plumbing.
That said, no one is stopping anyone from working on IPv4, so what personal freedoms are being impacted by working toward deploying IPv6, with an eye toward sunsetting IPv4 in the future?
Keep in mind that IPv4 started out as an experiment that found its way into wider use. It's a classic case of a test deployment that suddenly mutated into a production service. Why should we continue to expend effort to perpetuate the sins of the past, rather work toward getting v6 into wider use?
Is IPv6 a perfect protocol? Absolutely not, but it addresses the key pain point of IPv4 - address space exhaustion.
Thank you jms
On Sat, Mar 26, 2022 at 9:35 AM Abraham Y. Chen <aychen@avinta.com> wrote:
3) Re: Ur. Pts. 5) & 6): I believe that there is a philosophic / logic baseline that we need to sort out, first. That is, we must keep in mind that the Internet community strongly promotes "personal freedom". Assuming that by stopping others from working on IPv4 will shift their energy to IPv6 is totally contradicting such a principle. A project attracts contributors by its own merits, not by relying on artificial barriers to the competitions. Based on my best understanding, IPv6 failed right after the decision of "not emphasizing the backward compatibility with IPv4". It broke one of the golden rules in the system engineering discipline. After nearly three decades, still evading such fact, but defusing IPv6 issues by various tactics is the real impedance to progress, not only to IPv4 but also to IPv6.
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Thu, Mar 31, 2022 at 5:36 AM Jacques Latour <Jacques.Latour@cira.ca> wrote:
Exactly what I was asking, when and how will we collectively turn off the lights on IPv4?
Working on the World IPv6 Launch {day|week|forever} efforts, I noticed an interesting pattern of companies that put up IPv6 resources, with all the associated quad-As, and patted themselves on the back for making themselves available via IPv6; but I couldn't request those quad-A records via anything but IPv4 transport to their DNS servers. I've seen similar behaviour with hardware vendors. They have great IPv6 support, their boxes forward and accept IPv6 packets just fine; but, the deeper you dig, the more you find oddities, like syslog host destinations that only accept v4 IP addresses, or a requirement for an IPv4 router ID to be configured. I don't think we fully grasp just how wide the chasm is between "we support IPv6" and "we can fully turn off IPv4". There's a whole lot of "we support IPv6" in the world right now that comes with lingering IPv4 tendrils that are often under the surface, or in the darker corners of the config, that just keep working because most of the IPv6 world is still either dual-stacked, or has a translation layer that allows the lurking v4 bits to not cause issues. I don't think we'll be nearly as close to being ready to turn off the lights on IPv4 as we think we are, not just because of old customer CPE and legacy boxes, but because of embedded assumptions deep in software and firmware stacks. For example, let's take a relatively modern enterprise wireless platform: https://www.arubanetworks.com/techdocs/AOS-CX/10.07/HTML/5200-7852/Content/C... " - ZTP operations are supported over IPv4 connections only. IPv6 connections are not supported for ZTP operations." Sure, the devices pass IPv6 traffic just fine; but you'd better keep your IPv4 network around so the devices can configure themselves after powering on. There's a *lot* of code out there that's been carried forward for years, with dark corners that haven't been touched for a while. I think we're going to be stumbling over "can't do that over IPv6 yet" areas for years and years to come, not because of any willful myopia around the migration from IPv4 to IPv6, but simply because it's code that doesn't get used very often, and in dual-stack networks, it just keeps working the few times it gets exercised. The only time it would run into a problem is in a pure IPv6-only network; and how many of those really exist in the world to flag it as an issue? And yet, in order to "turn off the lights on IPv4", we're going to have to root through all those dark corners of code that haven't been touched in years to update them to work in an IPv6-only world; and that's *really* pushing the rock uphill, because that's work that isn't going to see any cost recovery for it at all. No customer is going to say "I won't buy your product until you've rooted out every bit of IPv4-only code in your software". So, there's really no financial incentive for companies to work towards getting their software ready for an IPv6-only world. So--the tl;dr version of my answer to you? "when" is likely to be "not in any of our lifetimes"--because the "how" requires completely non-monetizable effort on the part of companies that have legacy codebases they're carrying forward. Thanks! Matt
On 2022-03-31, at 20:54, Matthew Petach <mpetach@netflight.com> wrote:
And yet, in order to "turn off the lights on IPv4", we're going to have to root through all those dark corners of code
The part that you might be missing is that those dark corners are also where the vulnerabilities hide. If a piece of software can’t do v6, it probably hasn’t been maintained for a long time. With software bills of materials coming up, we may have a bit more leverage on these graveyard decks than we have had until now. Your main argument unfortunately does hold water; the timeline you propose, maybe not so much. Grüße, Carsten
You have to try running IPv6 only occasionally to weed out the dependencies. You can do this on a per node basis. Just turn off the IPv4 interface and see how you run. I do this periodically on my Mac and disable IPv4. This also makes my recursive nameserver IPv6 only as well. You then see what breaks like sites where one of the cdn’s is IPv4 only despite the page itself being reachable over IPv6. Or the nameservers are not reachable over IPv6. Write down what you find is broken and report it. -- Mark Andrews
On 1 Apr 2022, at 05:53, Matthew Petach <mpetach@netflight.com> wrote:
On Thu, Mar 31, 2022 at 5:36 AM Jacques Latour <Jacques.Latour@cira.ca> wrote: Exactly what I was asking, when and how will we collectively turn off the lights on IPv4?
Working on the World IPv6 Launch {day|week|forever} efforts, I noticed an interesting pattern of companies that put up IPv6 resources, with all the associated quad-As, and patted themselves on the back for making themselves available via IPv6; but I couldn't request those quad-A records via anything but IPv4 transport to their DNS servers.
I've seen similar behaviour with hardware vendors. They have great IPv6 support, their boxes forward and accept IPv6 packets just fine; but, the deeper you dig, the more you find oddities, like syslog host destinations that only accept v4 IP addresses, or a requirement for an IPv4 router ID to be configured.
I don't think we fully grasp just how wide the chasm is between "we support IPv6" and "we can fully turn off IPv4".
There's a whole lot of "we support IPv6" in the world right now that comes with lingering IPv4 tendrils that are often under the surface, or in the darker corners of the config, that just keep working because most of the IPv6 world is still either dual-stacked, or has a translation layer that allows the lurking v4 bits to not cause issues.
I don't think we'll be nearly as close to being ready to turn off the lights on IPv4 as we think we are, not just because of old customer CPE and legacy boxes, but because of embedded assumptions deep in software and firmware stacks. For example, let's take a relatively modern enterprise wireless platform:
https://www.arubanetworks.com/techdocs/AOS-CX/10.07/HTML/5200-7852/Content/C... " ZTP operations are supported over IPv4 connections only. IPv6 connections are not supported for ZTP operations." Sure, the devices pass IPv6 traffic just fine; but you'd better keep your IPv4 network around so the devices can configure themselves after powering on.
There's a *lot* of code out there that's been carried forward for years, with dark corners that haven't been touched for a while. I think we're going to be stumbling over "can't do that over IPv6 yet" areas for years and years to come, not because of any willful myopia around the migration from IPv4 to IPv6, but simply because it's code that doesn't get used very often, and in dual-stack networks, it just keeps working the few times it gets exercised. The only time it would run into a problem is in a pure IPv6-only network; and how many of those really exist in the world to flag it as an issue?
And yet, in order to "turn off the lights on IPv4", we're going to have to root through all those dark corners of code that haven't been touched in years to update them to work in an IPv6-only world; and that's *really* pushing the rock uphill, because that's work that isn't going to see any cost recovery for it at all. No customer is going to say "I won't buy your product until you've rooted out every bit of IPv4-only code in your software". So, there's really no financial incentive for companies to work towards getting their software ready for an IPv6-only world.
So--the tl;dr version of my answer to you? "when" is likely to be "not in any of our lifetimes"--because the "how" requires completely non-monetizable effort on the part of companies that have legacy codebases they're carrying forward.
Thanks!
Matt
On Thu, Mar 31, 2022 at 2:01 PM Mark Andrews <marka@isc.org> wrote:
You have to try running IPv6 only occasionally to weed out the dependencies. You can do this on a per node basis. Just turn off the IPv4 interface and see how you run. I do this periodically on my Mac and disable IPv4. This also makes my recursive nameserver IPv6 only as well. You then see what breaks like sites where one of the cdn’s is IPv4 only despite the page itself being reachable over IPv6. Or the nameservers are not reachable over IPv6.
Write down what you find is broken and report it.
-- Mark Andrews
This reminds me of days gone by, when NANOG used to have an IPv6-only hour in the agenda, where IPv4 connectivity would be turned off, so people could identify problem areas. Unfortunately, it tended to mostly be an excuse to head to the coffee bar, or enable "offline" mode in your mail client before it started, with little active engagement in the room. It might be interesting for NANOG86 in Hollywood to make it a formal part of the agenda; not just an hour with no IPv4, but a focused half-an-hour in which the focus of the room is on identifying problem areas; display an anonymized "word cloud" on the screens in the room and remotely that people can list sites, vendors, protocols, anything that they observe failing to function from the point of view of an IPv6-only client. We've talked about the need for people to "name-and-shame" in order to get movement from some software and hardware vendors, but people are often understandably reluctant to put their name on a 'name-and-shame' post that could jeopardize their job. Would doing it through an anonymized word cloud give people more air coverage to list items they see that don't work in an IPv6-only world? (Clearly, there's limits; if you're the only employee of a company, and you discover your employer's VPN endpoints don't work from a v6-only network, you might think twice about listing it in the word cloud--anonymization can only do so much to protect you!) A forum leader at the microphone, making suggestions for services people should test, functions they could try to exercise, sites they could try to reach to start the ball rolling; and then as the word cloud starts to fill in, solicit people's input on similar services to see if they fare any better. In fact, having two word clouds, red (doesn't work) and green (does work) might be an even better idea, so that it's not just a name-and-shame, but also a name-and-praise session, thanking those who have done the work to make v6-only connectivity work, and calling out those who still have work to do. Or is this a ship that has already sailed, and attempting to resurrect it will do nothing more than goose coffee sales for a brief interval? Thoughts and feedback welcome! Matt
participants (5)
-
Carsten Bormann
-
Jacques Latour
-
Mark Andrews
-
Masataka Ohta
-
Matthew Petach