nuintari's rules of networking 0x45:
-
nuintari's rules of networking 0x45:
IPv6 is not, nor ever was mutually exclusive with IPv4. Don't inflict extra misery upon yourself and your users by insisting that it is.
-
nuintari's rules of networking 0x45:
IPv6 is not, nor ever was mutually exclusive with IPv4. Don't inflict extra misery upon yourself and your users by insisting that it is.
@nuintari ...unless RFC 1918 exhaustion is an actual problem that IPv6 is solving for you.
-
@nuintari ...unless RFC 1918 exhaustion is an actual problem that IPv6 is solving for you.
@jima yes, but remember, I come from the ISP world, and I have been fighting the good fight against CGNAT for the last half of my career. I firmly believes ISPs should still provide a routable v4 address whenever possible.
.... and I'm usually losing that battle.
-
@jima yes, but remember, I come from the ISP world, and I have been fighting the good fight against CGNAT for the last half of my career. I firmly believes ISPs should still provide a routable v4 address whenever possible.
.... and I'm usually losing that battle.
@nuintari IMO, that's a very America-centric presumption, which hasn't played out in much of the world for a very long time — if ever, in some places, I assume, based on:
https://en.wikipedia.org/wiki/List_of_countries_by_IPv4_address_allocation
-
@nuintari IMO, that's a very America-centric presumption, which hasn't played out in much of the world for a very long time — if ever, in some places, I assume, based on:
https://en.wikipedia.org/wiki/List_of_countries_by_IPv4_address_allocation
@nuintari Also, WTF. 🤨
-
@nuintari IMO, that's a very America-centric presumption, which hasn't played out in much of the world for a very long time — if ever, in some places, I assume, based on:
https://en.wikipedia.org/wiki/List_of_countries_by_IPv4_address_allocation
@jima Fair point. I am the some of my own experiences.
In the USA, we are still dealing with people who want to debate whether IPv6 is ready for prime time, or even feasible. Meanwhile, there are nations that have been IPv6 heavy for over a decade now.
The world I live in, you have to maintain connectivity to both stacks somehow. I probably need to update some of the rules with corollaries. if you can actually exist without v4, consider doing it.
-
@jima Fair point. I am the some of my own experiences.
In the USA, we are still dealing with people who want to debate whether IPv6 is ready for prime time, or even feasible. Meanwhile, there are nations that have been IPv6 heavy for over a decade now.
The world I live in, you have to maintain connectivity to both stacks somehow. I probably need to update some of the rules with corollaries. if you can actually exist without v4, consider doing it.
@nuintari Oh, I'm not disputing the very real continued need to maintain _connectivity to_ IPv4 for now (and likely for some time)...I just have zero desire to maintain both stacks across the entire network, if I can help it, and if I'm choosing a single stack, it's gonna be IPv6.
Generally speaking, you're gonna have to NAT your Internet-bound v4 traffic any which way; I don't see the big philosophical difference between using NAT64 versus NAT44 to do so.
-
@nuintari Oh, I'm not disputing the very real continued need to maintain _connectivity to_ IPv4 for now (and likely for some time)...I just have zero desire to maintain both stacks across the entire network, if I can help it, and if I'm choosing a single stack, it's gonna be IPv6.
Generally speaking, you're gonna have to NAT your Internet-bound v4 traffic any which way; I don't see the big philosophical difference between using NAT64 versus NAT44 to do so.
@jima yeah, I haven't looked at this rule in many years now, it is high time for an update.
My current stance is more:
Dual-stack when feasible and significant v4 access is still required.
Avoid CGNAT like the plague it is. NAT44 isn't nearly as awful to deal with. While fudementally the same basic thing, CGNAT is a very service provider centric thing, and it comes with a whole host of issues for the end users.
Single-stack with NAT64 when practical.But, back to your original point. If you are facing RFC1918 exhaustion, you likely already looked into single stack and NAT64. if you didn't, you should be out of a job. The rule was originally aimed at people who had yet to invest in IPv6 at all. Going from v4 only to v6 only with NAT64 is a rather tall order. Dual stack is the far easier next step.
But yeah, the rule needs rewritten. I think I first coined this one in 2015, it was part of the original Twitter rant that later became the rules.
-
@nuintari ...unless RFC 1918 exhaustion is an actual problem that IPv6 is solving for you.
I have at one point in my career taken part in renumbering a network because of RFC 1918 addresses running out. A few years later the network was running out of RFC 1918 addresses again.
RFC 4193 is not the solution in that case. No doubt RFC 4193 is better than RFC 1918 in most cases. But a /48 RFC 4193 prefix divided into /64 link prefixes doesn't give you anymore segments than 10/8 divided into /24s.
There are other ways to allocate IPv6 addresses which solves that problem. But there doesn't seem to be consensus on how it should be done.
-
I have at one point in my career taken part in renumbering a network because of RFC 1918 addresses running out. A few years later the network was running out of RFC 1918 addresses again.
RFC 4193 is not the solution in that case. No doubt RFC 4193 is better than RFC 1918 in most cases. But a /48 RFC 4193 prefix divided into /64 link prefixes doesn't give you anymore segments than 10/8 divided into /24s.
There are other ways to allocate IPv6 addresses which solves that problem. But there doesn't seem to be consensus on how it should be done.
@kasperd M&A-heavy enterprises are _constantly_ running out of RFC 1918 space, since each acquisition brings a brand new RFC 1918 network that invariably conflicts with most of yours.
For some of these companies, renumbering isn't a one-and-done thing; it's a continual, never-ending time/resource sink.
But they'll still confidently assert that IPv6 won't help them.
-
@nuintari Also, WTF. 🤨
Now I want to know who wrote that song. Who doesn't like some country music?
-
@jima yeah, I haven't looked at this rule in many years now, it is high time for an update.
My current stance is more:
Dual-stack when feasible and significant v4 access is still required.
Avoid CGNAT like the plague it is. NAT44 isn't nearly as awful to deal with. While fudementally the same basic thing, CGNAT is a very service provider centric thing, and it comes with a whole host of issues for the end users.
Single-stack with NAT64 when practical.But, back to your original point. If you are facing RFC1918 exhaustion, you likely already looked into single stack and NAT64. if you didn't, you should be out of a job. The rule was originally aimed at people who had yet to invest in IPv6 at all. Going from v4 only to v6 only with NAT64 is a rather tall order. Dual stack is the far easier next step.
But yeah, the rule needs rewritten. I think I first coined this one in 2015, it was part of the original Twitter rant that later became the rules.
@nuintari I was once given a rather ambitious project to go from v4-only to v6-only, on a rather large, complex network.
The technical aspects were not the hard part, nor the cause of the project's demise.
-
Now I want to know who wrote that song. Who doesn't like some country music?
@kasperd A lot of people!
-
@nuintari I was once given a rather ambitious project to go from v4-only to v6-only, on a rather large, complex network.
The technical aspects were not the hard part, nor the cause of the project's demise.
@jima No, I wouldn't suspect it would be. I'm not saying you can't go from v4 to v6, but without some intermediate steps would make it harder. I would never try to go: add v6 to this device, remove v4..... add v6 to the next device, remove v4. I would go in waves, adding v6, confirming stability before I even considered dropping a single device off of v4. This method is mentioned by at least one of my other rules. I've done it several times, but again, never to full v4 removal. I work in ISP land after all. Hell, my own house still doesn't have v6 everywhere, but I only got stable v6 from my provider just under a year ago, so cut me some slack. Tunnelbrokers have long stopped being a viable option.
I will say, if my next ISP gig decides to go CGNAT, I will probably go full NAT64 for it, and ignore the RFC6598 space altogther. But that promised gig has yet to actually materialize and I'm not holding my breath. They were also debating buying a /19 to get started, in liue of buying CGNAT hardware.
As for why your assignment ultimately failed. I am going to venture a guess it had something to do with the original target of this rule: IPv6 naysayers who firmly believe the two cannot coexist in any way shape or form. A lot of ID10Ts out there.
-
@jima No, I wouldn't suspect it would be. I'm not saying you can't go from v4 to v6, but without some intermediate steps would make it harder. I would never try to go: add v6 to this device, remove v4..... add v6 to the next device, remove v4. I would go in waves, adding v6, confirming stability before I even considered dropping a single device off of v4. This method is mentioned by at least one of my other rules. I've done it several times, but again, never to full v4 removal. I work in ISP land after all. Hell, my own house still doesn't have v6 everywhere, but I only got stable v6 from my provider just under a year ago, so cut me some slack. Tunnelbrokers have long stopped being a viable option.
I will say, if my next ISP gig decides to go CGNAT, I will probably go full NAT64 for it, and ignore the RFC6598 space altogther. But that promised gig has yet to actually materialize and I'm not holding my breath. They were also debating buying a /19 to get started, in liue of buying CGNAT hardware.
As for why your assignment ultimately failed. I am going to venture a guess it had something to do with the original target of this rule: IPv6 naysayers who firmly believe the two cannot coexist in any way shape or form. A lot of ID10Ts out there.
@nuintari Oh, there was a plan, a reasonably solid plan, but even if there hadn't been, I've done v6-only in the enterprise before, and know a reliable process (which is exactly what you describe).
You're half-right about the problem, but it's even more basic: folks in positions of authority who confidently assert that IPv6 wasn't even needed in the first place.
-
@nuintari Oh, there was a plan, a reasonably solid plan, but even if there hadn't been, I've done v6-only in the enterprise before, and know a reliable process (which is exactly what you describe).
You're half-right about the problem, but it's even more basic: folks in positions of authority who confidently assert that IPv6 wasn't even needed in the first place.
@jima Oh yeah, v6 migrations are so much easier than the naysayers have decided to hold as a firm doctrinal belief. Drives me fracking nuts. I've had two networks that were 100% IPv6 ready under my watch rip the v6 stack out entirely after I was gone, because the new network engineer felt it, "needed further testing."
Hell, Spectrum did this to TWC when they acquired them. I had working DHCPv6-PD in 2016. Spectrum ripped it all out in 2017. I just got a working WAN v6 address back like.... a year ago.
As for the decision makers who think, "This sounds hard and expensive." The worst, especially when you have a couple loud mouthed IPv6 opposers grabbing for their ears, essentially making the bad decisions for them.
I still say that the biggest roadblock to IPv6 adoption is shitty techs.
-
I have at one point in my career taken part in renumbering a network because of RFC 1918 addresses running out. A few years later the network was running out of RFC 1918 addresses again.
RFC 4193 is not the solution in that case. No doubt RFC 4193 is better than RFC 1918 in most cases. But a /48 RFC 4193 prefix divided into /64 link prefixes doesn't give you anymore segments than 10/8 divided into /24s.
There are other ways to allocate IPv6 addresses which solves that problem. But there doesn't seem to be consensus on how it should be done.
@kasperd the thing with ULA is if you burn through a full /48 ULA, you...just get another /48 of ULA...and another...and another. If you burn through 10/8, you play games with 172.16, and 192.168, or even 100.64 and 240/4, each step of the way getting more desperate and increasing your risk of collisions with other entities or starting to gamble on how networking devices handle those weirder prefixes (that aren't intended for those use cases anyway).
If you have a need for ULA, you're not going to hit those same restrictions.
Or you just get yourself a proper /32 and do it right.
-
@kasperd M&A-heavy enterprises are _constantly_ running out of RFC 1918 space, since each acquisition brings a brand new RFC 1918 network that invariably conflicts with most of yours.
For some of these companies, renumbering isn't a one-and-done thing; it's a continual, never-ending time/resource sink.
But they'll still confidently assert that IPv6 won't help them.
The experience I had was due to growth. Acquisitions is a different story. Had those companies used RFC 4193 instead of RFC 1918 they wouldn't have that problem. But if you do acquire two companies who both did RFC 4193 wrong you will have to renumber anyway.
