We're pushing to get IPv6 deployed and working everywhere in our operation, and I had some questions about best practices for a few things.
On your management nets (network device management nets) , what's the best approach for addressing them? Do you use ULA? Or do you use global addresses and just depend on router ACLs to protect things? How close are we to having a central registry for unique local addresses, and will that really happen?
What if you apply to a /48 block as end-user because the management
network is not part of your ISP-related /32 or larger block ?
What if you happen to get that /48 and never announce it to the DFZ ?
Then your attack surface gets very small (but still exists, you'll
need some ACLs here and there, notably your customers having
default-routes to your core).
We're pushing to get IPv6 deployed and working everywhere in our
operation, and I had some questions about best practices for a few things.
On your management nets (network device management nets) , what's the best
approach for addressing them? Do you use ULA? Or do you use global
addresses and just depend on router ACLs to protect things? How close are we
to having a central registry for unique local addresses, and will that
really happen?
ACL are prone to typos and inconsistent deployment. If the security policy
is that a give interface must not talk to the internet, ULA is a good choice
as part of a multi-layer security strategy
At some point you will have to manage something outside your current world or your organization will need to merge/partner/outsource/contract/etc with someone else's network and they might not be keen to route to your ULA space (and might not be more trustworthy than the internet at large anyhow). Think about things like VPN endpoints, video devices, telephones, etc, that may end up on a public network, maybe behind a device you manage. You may just manage routers today, but who knows about tomorrow. Put behind a firewall and use good ingress filtering throughout your network, separating trust zones with distinct subnets.
If you are worried about forgetting to enable a firewall, put in a network management system to verify connectivity stays blocked combined with a monitored IDS.
I couldn't agree more. If you set up private address space, it's going
to come back and make more work for you later. Set up public IPv6
addresses. If you need stateful connection filtering, put in a
stateful firewall.
If you really really need address obfuscation, you can still do NAT,
but NAT from public addresses to public a public address or pool of
public addresses. If you ever need to turn off NAT, it's a lot easier
than renumbering hundreds of machines and you always have the option
of disabling it per-host instead of doing an all-or-nothing
transition.
We allocate a /64 per subnet as that's what most of the management hosts expect.
We also build the CoPP/ACLs in a comparable way for the ipv6 afi as one does for the ipv4 afi to protect the device from unauthorized access.
having access to a trusted net will get you a response to your SYN, you still need the ability to auth past that point to various devices/systems. Getting on that trusted net and protecting it is clearly something important.
Certainly one can go crazy with trying to secure ones networks by wrapping it in 802.1x with various backing systems. I do recommend making sure your security practices are sensible and not forgotten. Nothing like having a machine on the 'trusted' lan becoming compromised. Never know what's going to happen
We our designing a new hosted exchange environment as well as Multi-Tenant Desktop as a Service environment and we are going to use IPv6 public address.
You can also use IPv6 privacy extensions (by default on Windows 7),
see rfc4941. For Linux, you can also enable it, which is not a
default.
In the context of "addresses I'm using to manage kit", having devices randomly renumber themselves at regular intervals does *not* sound like it's going to make my life easy
Remember, every interface has multiple addresses in IPv6. While I
don't know if Linux behaves similarly, for Windows, the privacy
address is primarily used for outbound connections. The MAC-derived
IPv6 address is also still active, and is the one registered
automatically in DNS, so you would still reach your kit via stable
addresses (well, as stable as the physical network interface).
In IPv4 most people use static assignments for servers, and often use
dynamic assignments for client hosts (e.g., DHCP). The IPv6 world is not
different. If you don't want privacy addresses for your servers (and
it's unlikely that you would) you just make sure that they are not enabled.
That only helps you in situations where entering an IPv6 is unsupported
because the parser chokes on the ':' or does not support scope
identifiers. The app itself still needs to resolve that literal using
getaddrinfo() into a valid IPv6 address (and scope-id) for it to make
any sense of it.
For apps that don't support IPv6 the only way you are (likely) getting
them to to talk to IPv6 capable services is to proxy them.
Good old SOCKS is a great one there and otherwise one of the various TCP
forwarders (on windows one can use: netsh interface portproxy add v4tov6
listenport=80 connectaddress=theipv6nox connectport=80)