Im interested in thoughts for a scenario where you want to do small-scale multi-site activities, with site-to-site connectivity.
Here’s a couple of constraints:
-
you’re not going to pay the money to get an assignment, you’ll just have ISP global.
-
your two or more sites will have different ISPs.
-
You’re doing VPN between sites instead of provider managed. The sites might be running some normal enterprise services like active directory, or other internal corporate norms.
-
you might have the need for a backup Internet connection. Load balancing would not be required.
With the fact that the globals could change at a site, would you consider using ULA? Or just stick with global and update DNS in the event of change. I know there’s a preference problem with ipv4 being chosen over ULA, so the ULA thing wouldn’t be very easy unless you went straight v6.
If ULA, would you pattern/convention match the global in each site or create one organization wide ULA and assign it something like /48 per site?
What precautions do you take on gateways to ensure globals aren’t used outside of the tunnel? ULA prevents this, but so does proper configuration I assume.
How would you do this?
I keep asking about ULA because I heard/read enough articles where the author says don’t do it, but they seem to be geared at large enterprise or hosting where they would definitely get dedicated blocks, peering, etc. I’m interested in the little guy.
I’ll take a stab at this, although I profess no professional experience in network management and my interest in IPv6 is primarily in advocacy and in homelabs. With that said…
This seems like a situation where ULAs make some sense, but only for inter-site traffic. So I’d probably first provision for global addressing from each site’s ISP. Then overlay ULA addressing to those sites as well, carving /48 subnets using the procedure from an RFC that I can’t remember, so that the prefixes are randomized. This reduces the chance that a future site will conflict, as well as any conflicts due to mergers and acquisitions of the company.
Keeping the ULA traffic off the WAN is relatively easy with a reject rule on egress, and the ISP should be dropping that traffic anyway. Keeping global traffic off of the tunnels can be done the same, with reject rules if a non ULA src or dst address is used.
DNS for internal site resources can use ULA just fine, unless you absolutely need reverse DNS. For resources needing exposure externally, I’m not sure if this plan accommodates that.
TL:DR: use both ULA and global addresses. Routing rules to reject.
Split-horizon DNS is a thing that exists. This part is a solved problem.