Replies: 2 comments 2 replies
-
That seems incredibly optimistic. I've always been a fan of traditional dual stack when there is a large operational IPv4 legacy that will likely take years to clear. On the other hand, going straight to IPv4-as-a-service is a bigger initial workload but at least in theory significantly reduces OPEX. We do cover this at [1] and [2] but what we really need is a case study in Chapter 7. There is always some confusion, because until IPv4 is truly dead (i.e. for ever, as far as I can see), apps still need to see a dual-stack socket API, but with IPv4-as-a-service there are no native IPv4 packets on the wire so no dual-stack routing. Anyway, how about writing a case study based on your new project? [1] https://github.com/becarpenter/book6/blob/main/3.%20Coexistence%20with%20Legacy%20IPv4/3.%20Coexistence%20with%20Legacy%20IPv4.md |
Beta Was this translation helpful? Give feedback.
-
Perfect candidate for a case study for chapter 7! Get writing?? |
Beta Was this translation helpful? Give feedback.
-
I'll start working on a new old IPv6 project shortly, and their current plan is to enable dual-stack everywhere and then go from there to IPv6 only in the coming year. From my point of view forcing dual-stack makes more work, think configuration, monitoring, troubleshooting, and should be avoided if possible. So kind of dual-stack where you must, single stack IPv6 where you can and maybe keep IPv4 only for things that have to be replaced in the (near) future anyway.
I think there should be something about this in the book.
Beta Was this translation helpful? Give feedback.
All reactions