best practices for management nets in IPv6

Hi All,

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?

Tom

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).

Rubens

Hi All,

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

Cb

Public IPs.

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 :slight_smile:

- Jared

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.

Cheers
Ryan

Well,

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.

Steph

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 :frowning:

Regards,
Tim.

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).

Cheers,
Dave Hart

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.

We keep running into problem with our IPv6 roll out. I just confirmed
today that Exchange does not fully support IPv6

Cheers
Ryan

Which version of Exchange are you talking about, and can you share what
about it doesn't support IPv6?

Frank

Yes sorry Exchange 2010 - OCS, Lync, Exchange UM - these require IPv4

Cheers
Ryan

We keep running into problem with our IPv6 roll out. I just
confirmed today that Exchange does not fully support IPv6

[...]

Yes sorry Exchange 2010 - OCS, Lync, Exchange UM - these require
IPv4

It's a hack (but all ipv6 transition stuff is...) but have you tried
using ipv6-literal.net for the apps that don't work with ipv6 yet?

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)

Greets,
Jeroen