Dan sent me the following question:
I had another read of the ‘Building IPv6 Service Provider Networks’ material and can see the PE routers use site local ipv6 addressing. I’m about to build another small service provider setup and wondered: would you actually use site local for PE loopbacks etc, or would you use ULA or global addressing? I’m thinking ULA would be better from a security point of view?
TR&DR summary: Don’t do that.
First a bit of self-flagellation: I did use site local IPv6 addresses in router configurations and printouts (with the usual “reasoning” – preventing anyone from cut-and-pasting configurations without turning on their brains). I was wrong. Using ULAs wouldn’t be a good choice either. I should have used the documentation IPv6 prefix (2001:db8::/32).
Would ULAs make sense?
One wouldn’t gain much (from the security perspective) by using ULAs. Customers with default routes pointing toward your network could send packets addressed to your network devices anyway. You could stop that by implementing inbound packet filters on all customer-facing interfaces, but then you could as well drop packets addressed to your backbone.
On the other hand, packets sent from ULA addresses (and the network devices would send them – ULA addresses are perfectly valid IPv6 addresses) wouldn’t reach destinations in other autonomous systems (yet again, assuming someone in the path cares at least a bit about security), breaking path MTU discovery. Using ULAs in your public backbone is no different from using RFC 1918 IPv4 prefixes in public networks.
What could I do?
If you want to make your backbone unreachable from the outside world (and think it’s too hard or inconvenient to deploy simple ACLs on all ingress ports), you might consider using link-local addresses (equivalent to ip unnumbered), in which case you should start your exploration with a careful reading of Using Only Link-Local Addressing Inside an IPv6 Network IETF draft.
We migrated our blog a few days ago, and the commenting functionality is not there yet. In the meantime please find our content on LinkedIn and comment there.