Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have an ubuntu server (serverA) which has a couple of IPv6 addresses. One of these is based on it's MAC address, and is known to the network, the other one I presume ubuntu created as a 'private' address which hides the MAC address.

I have another server (serverB) which hosts a database, and requires an incoming connection from serverA. serverB has a firewall, only allowing incoming connections from serverA. I've specified serverA's MAC-based IP address in serverB's firewall exceptions, but not knowing the private address, didn't add this in. However, packers from serverA seem to be defaulting to come from the private address.

Is the private address deterministic? How can I disable it? Should I disable it?

share|improve this question
up vote 3 down vote accepted

The privacy address is supposed to be random, and change often. It shouldn't be deterministic; that would be antithetical to the concept. It should be used for outgoing connections.

I don't recommend disabling it, because it is useful for not disclosing your MAC like the SLAAC (the proper term for the MAC-derived address) does. However, some people who value the ability to determine which host made a connection later on prefer to disable it.

If you must use IP-based ACLs, you're going to have to disable it. You can do so by adding ip6-privacy=0 to the ipv6 section of /etc/NetworkManager/system/connections/. You may also want to inspect /etc/sysctl.d/10-ipv6-privacy.conf if that doesn't put a stop to it.

share|improve this answer
You mention IP-based ACLs - are there any alternatives at the network/firewall level? Would a DNS-based firewall be any better in this case, as the private address is not static, hence not ideal for DNS? Are you suggesting dropping the firewall and relying on application-level security? – askvictor Jul 18 '13 at 6:46
I find that there is only very rarely any reasonable use case for egress IP-based ACLs. If you happen to have one, you probably can't use ipv6 privacy extensions is all. You could certainly assign a static address that is not a SLAAC, though really this is no better than using the SLAAC from a security standpoint. – Falcon Momot Jul 18 '13 at 17:23
I don't care about the egress from serverA; it is the ingres ACL on serverB that was causing the issue. – askvictor Jul 18 '13 at 21:58

I will focus on your last question: Should you disable private addresses?

I agree with @Falcon that Privacy Extensions as defined in RFC 4941 are useful. I would always enable them on clients/workstations that may connect to services on the Internet, and I hope mobile phone producers will soon enable them per default on all their devices.

But in your setup, you are talking about two servers, where one of them is (not only, I assume) acting as a client to the other server. First questions would be: What is your setup? Are these servers within your company network? What external access will they have? Will serverA ever connect to the Internet (without a proxy)? If all traffic is internal and you do not see a threat by an adversary that maps your internal network traffic patterns, just disable Privacy Extensions on the servers. A server must by definition have at least one address that is well-known to its clients, mostly via DNS, so an attacker can use this address to attack the server. Hiding its address is not a valid attack mitigation strategy for a server. (Placing load balancers in front with its address is, of course.)

The US "DoD IPv6 Standard Profiles For IPv6 Capable Products" (sorry, I could not find a link to a version newer than 5.0) also demand Privacy Extensions for hosts/workstations "that will operate on networks requiring privacy address extensions or otherwise need to maintain anonymity" and strongly recommend them for other hosts/workstations. This requirement goes for servers only if they also act as clients (as in your setup) and need to maintain anonymity (which you must decide). So, the general server does not need Privacy Extensions activated.

Concerning the ACLs: If hard-coded IPv6 addresses must be used in several places, I would even consider defining fixed IPv6 addresses on your servers. You can set them on the servers and DNS or distribute them via DHCPv6, but you will have less work, compared to SLAAC addresses, if you ever have to replace a NIC or a server.

So, in short: If your servers only communicate internally and do not have advanced security requirements against traffic analysis, you should disable Privacy Extensions. In any other case, you must balance your pros and cons.


share|improve this answer
Thanks; serverA will connect to the Internet occasionally. Both servers are virtual so movement isn't really a problem, but I think I'll move to a static, non-SLAAC address. – askvictor Jul 18 '13 at 22:26

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.