Listen, Subscribe & Follow:
In this episode of IPv6 Buzz Ed, Scott, and Tom discuss “IPv4 thinking”, what exactly it is, how it can be harmful to your IPv6 migration efforts, and—most importantly—how to avoid it.
Topics discussed include:
- How is IPv4 thinking particularly detrimental to IPv6 address planning?
- How IPv4 thinking often ignores IPv4 techincal debt
- What IPv4 thinking is and how it can impede your IPv6 design, architecture, and operation
- Decoupling IPv4 thinking from IPv6 adoption and the resulting benefits
Thanks for listening!
Sponsor: Juniper
User experience matters. Sponsor Juniper Networks invites you to attend a free SD-WAN demonstration to see exactly how to deliver a great user experience from client to cloud. Learn how session-based visibility and fine-grained application-aware Session Smart Routing brings huge benefits. Sign up at juniper.net/sdwan-demo.
Show Links:
IPv6 Buzz 101: Innovating With IPv6 – Packet Pushers
Your Hosts:
Share this episode
The IPv4 Thinking goes beyond IPv4. Much of our L2 games that now involve VLANs and bridging, and the like are because of IPv4 limitations.
It goes beyond IPv4 scarcity, but to the concept that we have to L2 bridge everything.
So we get into STP, and all sorts of L2 games.
While listening to the part about mapping IPv4 addresses onto IPv6 addresses, it reminded me of something I ran into recently. A customer’s web host was migrating to a large cloud provider. The web host provided instructions for updating DNS that included a CNAME entry for the www record and four A entries for the “bare domain” but no AAAA entries. The old entries included AAAA records for the bare domain and I knew the cloud provider supported IPv6, so I was a little disappointed that the new service wouldn’t and I started digging.
The CNAME targets included two of the A records that matched what they provided for the bare domain and two AAAA records, so I added those two AAAA records to the bare domain. Problem solved, but for completeness, I wanted the AAAA records for the other two hosts in the bare domain.
I noticed that the last 32 bits of the AAAA records were the hex encoded A records, so I checked the hex encoded versions of the other two and they were indeed serving the same content. I added the other two AAAA records and everything is working great.
It appears as if this cloud provider gives every one of its customer hosts with an IPv4 address an IPv6 address with the IPv4 address encoded.
Now I’m thinking about going through all of my other customers that use this could provider and making their sites work on IPv6 by just adding AAAA records. 🙂