IPv4 To IPv6 Migration Advice

Solution 1:

This seemed like overkill to me, we already wont come close to filling the single /64 but this might be my IPv4 mindset confusing me.

Stop counting hosts, that's IPv4 thinking. Subnets come in one size fits all, enormous. A /64 can address every IP device ever made with plenty room to spare.

Yet the address space is even bigger such that a single site can easily ask for a /48. 64 thousand /64s, 4 hex digits, to give out according to your desired address plan.

For the /48 what exactly do I do with it.

Whatever you want! Be generous and plan for growth. Give /64s to every subnet, every VLAN, wifi SSID, security zone, cloud and remote access VPNs, each container host, the "all zeros" /64 for vanity static service addresses, and so on.

Aggregate where possible, to avoid fragmentation. So perhaps delegate /60s or /56s to internal networks like your DHCP server, manual assigned static pool, wifi controller, or container orchestration system. And test environments for all of the above.

Does not have to be dynamic such as DHCP-PD, especially not if you have a static prefix from your ISP. But track things somehow, in an IPAM system.

Or there's graceful resolution if it does find a conflict?

IPv6 nodes are supposed to do duplicate address detection on all unicast addresses, stateless, DHCPv6, manual, or otherwise. Standard is to stop on duplicates rather than cause difficult to diagnose problems. Randomly generated addresses in a /64 have a very low chance of conflicts.

ULA

ULA is no Internet addressing. Being not globally reachable, standard default address selection policy puts them lower priority than even IPv4. See rfc6724. As such, you will want globally routable (not-ULA) addresses on hosts that get on the IPv6 Internet.

some kind of dynamic-dns equivalent.

Yes, DNS is necessary. Names are easier for humans than IPs.

Yes, knowing the IP is generally a choice between the DHCPv6 server having the state, and a SLAAC node being configured with a dynamic DNS client. Router advertisement flags A and M tell the client stateful or stateless.

AD DS joined hosts are fairly straightforward, it is expected they would add themselves to DNS.

Or perhaps, configure server interfaces with stateless, but with not-random EUI-64 based addresses. Then you can calculate the address beforehand based on the MAC address, and put that in DNS.

And maybe not all devices need to be in DNS. Should personal Android devices be allowed on guest Internet, they don't do DHCPv6. If not managed by a MDM, you won't know their IPs.

Solution 2:

First: get that /48. For security and manageability not putting everything in a single broadcast domain (VLAN) is good practice.

Second: for servers just configure the addresses statically. You can use SLAAC, DHCPv6 and static addresses on the same network if you want.

It's not very common to put IPv6 addresses of workstations in DNS, but there are use cases where it can be useful. For a business with stable addresses I would recommend against using ULA.

What I would do in your situation is to leave SLAAC enabled so users can get privacy addresses etc. Add a DHCPv6 server on the side that gives out fixed addresses and puts them in DNS if you need that. Also set the M flag in the Router Advertisements so that clients know there is a DHCPv6 server present.

And since IPv6 uses global addresses for everything, make sure you have proper network security like a firewall.

Solution 3:

Alternatively I have the option to ask the ISP for a /48, should I do that and advertise a single /64 for local clients to get connectivity and different /64 for static servers?

Absolutely ask your ISP for a /48. You cannot subnet a /64 without breaking all kinds of things (including SLAAC).

Your idea of putting servers and local clients on a different network is also a very good idea (even in IPv4). Of course, sometimes the network infrastructure does not allow you to do that (you need either separate wiring, or VLAN capability), but since you are asking the question, I assume that this is not an issue for you.

Segregating your network allows you to put a firewall between them. Since in IPv6, everything is a public IP address, it is far more essential than in IPv4 that you carefully fine tune your firewall; it is far too easy to accidentally leave systems directly on the Internet; that's one of the major weaknesses of IPv6. If you segregate your network, making such a mistake on one network will not automatically expose the other.

Also, if you segregate networks, if it makes sense you can implement a zero-trust approach on the server-side network (which may reduce the need for a firewall there), without having to do the same thing on the internal network.

Or you could migrate your servers and keep the workstations on an IPv4-only network; that reduces your workload, supports older devices that don't support IPv6, and has a number of other benefits (although some IPv6 advocates would argue against that).

Bottom line: as long as your infrastructure supports it, definitely segregate your network, there are a lot of upsides and no real downside.

As for your second question: it sounds like you are working on a decent-sized corporate network. I would highly recommend you implement an IPAM solution, instead of trying to roll your own.

The general answer for your situation is just as you suggested: stateful DHCPv6 with automatic updating of a DNS server. Most IPAM solutions basically are those two technologies, along with a management front end.

Edited to add: just for completeness, although it is probably not a good fit for you, you could also use mdns (aka bonjour or zeroconf) for name resolution.

Support for it is somewhat spotty. Apple usually supports it, Windows 10 partially supports it, but you have to manipulate the registry to make it work for traditional Windows applications, and I haven't been able to get it to work at all on Android.

Of course, mdns would also not address your question regarding updating the external DNS server.