20

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.

Max Ehrlich
  • 336
  • 3
  • 13
  • 1
    Related reading: [How does IPv6 subnetting work and how does it differ from IPv4 subnetting?](https://serverfault.com/q/426183/126632) – Michael Hampton Apr 14 '20 at 10:57

3 Answers3

17

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.

Community
  • 1
John Mahowald
  • 30,009
  • 1
  • 17
  • 32
  • 3
    It's worth repeating that in IPv6 you should think in terms of subnets rather than individual addresses. This is probably the hardest mental shift for someone accustomed to IPv4. – Michael Hampton Apr 14 '20 at 10:54
  • For ULA, my plan was (/is already set up) to only use those addresses so that people can query AAAA records they're still getting a GUA and if that is their source address for all connections that's fine by me, does that seem reasonable? – Max Ehrlich Apr 14 '20 at 17:40
  • Android devices and phones in general I was planning on using SLAAC, but while we're on the subject of the Lorenzo problem, I had heard that some companies came up with various solutions for it, is there any reading on how they did it? – Max Ehrlich Apr 14 '20 at 17:50
  • 1
    ULA is fine, for connections confined to that network. Such addresses can have AAAA records in the local DNS. But if you have A records of the same name, those have higher priority than ULA, unless you alter the host's selection policy. – John Mahowald Apr 15 '20 at 15:17
  • @JohnMahowald That didn't sound right to me, so I did some testing on an unaltered host, using both ssh and firefox, if I put in a hostname with a ULA AAAA record and an A record, I can see that it uses the ULA address for the destination and it's own ULA address for the source, not the IPv4 address. If I have a dummy AAAA record, I can see it waits for the IPv6 connection to time out before getting the A record and using that instead. – Max Ehrlich Apr 18 '20 at 19:00
  • Good that you tested ULA. If it works for you, sure use it. Address selection is a little more complicated than my simplification. When implementing dual stack with ULA, read the address selection RFCs, and get familiar with any customization to the tables on your hosts. Also realize that you have enough address space to use globally routable subnets on everything; ULA is not required for your first IPv6 experiment. – John Mahowald Apr 19 '20 at 10:20
  • I think what you're describing is covered by RFC 6724, but it seems like a lot of OSs are still using RFC 3484 so probably it is only working because of out of date networking practice – Max Ehrlich Apr 21 '20 at 21:05
9

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.

Sander Steffann
  • 7,572
  • 18
  • 29
  • Very interesting, a few follow-up questions. For the /48 what exactly do I do with it. Do I adverse a /48 prefix or do I use PD to some internal routers to break the network into random subnets? So you're saying do slaac, DHCP, static, in our public prefix not ula and I won't have to worry about slaac accidentally generating an address used elsewhere? Or there's graceful resolution if it does find a conflict? – Max Ehrlich Apr 13 '20 at 03:07
  • 2
    The most common thing I see for DNS is someone will be at a colleagues desk and say "oh I have data on my machine you can copy, but I don't know my IP, just ssh to mehrlich-laptop" for example – Max Ehrlich Apr 13 '20 at 03:13
  • 2
    You'd want servers and clients on separate networks with separate firewall policies anyway, and now that there's enough address space, you can finally do that. Servers use statically assigned addresses, clients use SLAAC, and since the networks are separate, there is no conflict. There would be a resolution mechanism, but the mixed network is bad style anyway. – Simon Richter Apr 13 '20 at 13:51
  • 1
    Why not use a ULA prefix for internal traffic? Your global prefix might change for various reasons e.g. you switch to another ISP, or your German ISP changes it every day, etc. – Michael Hampton Apr 13 '20 at 15:18
  • Based on everyones feedback, I immediately got the /48, and after re-reading some things it's obvious should have done that from the start. For DHCP what is the reason to prefer a DHCP GUA vs GUA from SLAAC and ULA from DHCP? – Max Ehrlich Apr 14 '20 at 17:41
4

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.

Kevin Keane
  • 860
  • 1
  • 8
  • 13
  • We're actually quite small, but I like to follow operational best practices as though we were large. Do you have a recommendation for an open source IPAM solution? – Max Ehrlich Apr 14 '20 at 17:47
  • @MaxEhrlich Sorry, I can't help with that. We are using a commercial solution (we just switched from BlueCat to ElasticIP, I believe. It is actually a different team, so I'm not involved with the details). – Kevin Keane Apr 22 '20 at 04:50
  • @MaxEhrlich Another thought that comes to mind is that best practices themselves aren't absolute, but depend on the network size, both now and projected for the next three to five years. One of the more general best-practices is YAGNI. You Ain't Gonna Need It. If your environment is small, with less than about a dozen servers, and you don't expect it to grow dramatically, it may well be more appropriate to manage a few servers manually with static IPs (or DHCP reservations) and manual DNS entries. Maybe create a few scripts and be done with it. Of course, your mileage may vary. – Kevin Keane May 10 '20 at 02:21
  • And our IPAM is EfficientIP. – Kevin Keane May 10 '20 at 02:21