I'm currently working on adding IPv6 capabilities to our network, and I have some questions on what is considered best practice in 2020 to convert some of the IPv4 concepts we are used to into the IPv6 world.
In the current setup that I have, we are allocated a /64 from the ISP, and the router advertises that prefix for clients to configure themselves using SLAAC. This seems to work fine and as far as I know everyone has IPv6 internet access.
However we like to be able to query things by name, and I'm not sure what the best practice is to provision AAAA records for the clients.
What I have done is deploy stateful DHCPv6 on the dnsmasq instance that runs our DHCPv4 and tell it to hand out ULAs from some range which naturally provisions AAAA records for anyone who asks for an address. This also seems to work fine, but I know there is some dislike of stateful DHCPv6. This also helps me to consolidate the assignment of the servers we have on static IPs exactly as I do for DHCPv4, these servers for various reasons should be accessible at a fixed IP address and we would like that to continue to be the case for IPv6.
The only other way I can think of to do the AAAA records is to send the dnsmasq machine the RA prefix from the router via unicast and then use the dnsmasq to advertise the GUA prefix for slaac using the ra-names option. This wouldn't solve the static address assignments though as far as I can tell and I'm not sure how reliable it actually is. Is there a better way to handle internal AAAA records than ULAs with stateful DHCPv6?
Finally, as things are starting to work, we are now looking at migrating our public services to IPv6. My understanding is that this would require a fixed GUA for the servers to provision public AAAA records. I'm not sure how to achieve this using SLAAC from the edge router, unless there is some kind of dynamic-dns equivalent. Can I again use DHCPv6 or another manual assignment method to pick IPs in our assigned prefix? I was hesitant to do this because I thought it might collide with a SLAAC address and I'm not sure what happens if there's a collision. 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? 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.
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.
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 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.
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.
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.
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.