IPv6 for Dummies: NSA pushes security manual on DoD admins The US National Security Agency (NSA) has published a guidance document for system administrators to help them mitigate potential security issues as their organizations transition to Internet Protocol version 6 (IPv6). The prosaically named "IPv6 Security Guidance" [PDF] was compiled for admins inside the Department of Defense …
Thank you for this. Worthy to note that the issue was posted from 2012 so one can only surmise this is quite intentional: mobile users are easier to track across networks when, as per NSA, SLAAC is being used. I am very, very sure that this benefits Google's advertising subsystems and therefore remains an open 'issue' in all versions of Android.
Only if the device isn't using privacy extensions, RFC7217, or randomized MACs.
I don't have any stats on deployed devices, but I suspect most of them have at least one of those turned on, so I doubt this helps Google's tracking much at all. Especially when most of their phones are signed in to a Google account and continuously phone home anyway.
It makes harder for some sites to control the devices themselves. With DHCP it's easier to log which devices got an IP and when. With SLAAC, not so much. Google wants its devices connected and being able to talk with the mothership always, whatever can get in the way is not good.
And the settings are under user control, AND may limit or complicate correlation of logs.
This won't end the holy wars, but in this context, DHCPv6 makes sense. You get control, visibility, and reliability for any device that recognizes it, and off the shelf tools to handle clients that don't and isolate them from the rest of your secure network.
it's a simple and effective way to mitigate IPv6 exploits
So is blocking IPv6 at the firewall..
(I really, really tried to set it up properly. I like to think I'm not entirely unintelligent and I've been doing network stuff for quite a while but I could only ever get two of the three working: external IPv6 to the firewall, internal IPv6, routing of internal to external. Part of it may well be that I was trying to use IPv6 auto-assignment and I suspect that my mix of Windows/FreeBSD/linux didn't entirely work together.. From an internal VM, I could ping6 the internal IPv6 firewall address, the firewall could see the inside *and* outside but anything internal couldn't see anything outside the firewall - not even the router. The router could see the firewall (and vice-versa) I had all the routes set correctly, the firewall was allowing the traffic. In the end I gave up and disabled IPv6 entirely. My ISP does support IPv6..)
Only, no, it isn't really simple, and running dual stack especially so. You need to correctly set duplicate policies and correct routing on all of your IPv6 links, when the ability to dynamically control client routing isn't a reliable option, or in many cases possible. So kiss a fast cut over on a fault tolerant network goodby. Kiss any real hope of deterministic networking and routing behavior goodby.
I get where your coming from, but while blocking it at the firewall stops one class of problems, it leave a broken mess dragging down your internal network.
We get two choices, kill it all everywhere if you can or make it work right everywhere on v6. The middle ground isn't worth the mess.
Strong medicine to be sure, but it saves living with a bunch of flat retarded behavior from client devices.
I tend to kill it on the switches if I have too, or things from Google or Apple will "invent" a bogus IPv6 network that doesn't go anywhere, and then because of the IPv6 precedence rule, you end up eating timeouts where things repeatedly try and fail at IPv6 first before switching to the IPv4 network that is actually routing. You also halve the broadcast traffic they shit onto your network as there is only an IPv4 copy sent, not both. (That may be more if you have more than one internet connection, as it may crap MDNS on IPv4, and EACH live IPv6 address. So if you have dual links and a backup line, plus a local address segment, you could be eating a 5 fold increase in garbage traffic as soon as you switch IPv6 back on. Worse if you have laptops with both wired and wireless connections, or WiFi only devices, which will then start grabbing addresses for all your IPv6 links and happily shitting them onto the WiFi segment.
Sadly, kill it with fire is less and less an option, but for sites that don't have a strict mandate for IPv6, turning it off may still be the least worst option.
Long out of this industry where I was digesting IPV6 info and documentation by the tanker load and its still not really adopted as envisioned.
I think I read the USA was slowest on the uptake. Its reasonable to assume they are holding back to watch others make all the mistakes.
Thank god I dont have to do another exam peppered with shite about ipv6.
Anyone else sick of constant cisco exams and jobs which dont even use the skills you supposedly have wasted your time and money on?
Just exist so some clueless arse will pick you cv out of the pile. Do they even do that anymore? Its Buzzword scans I guess now.
How do all the layers and layers of physical and logical security put in over years and years square with workers sat at home in their pyjamas working in the same room as someone who works for a competitor?
What a giant nsa style laugh.
Because DHCPv6 is default, present and strangely required there, apart from fully disabling IPv6 on Windows, you can pretty much take over everything fairly easily on Windows today with local network access. But, feel free to "school" me on this. To this date, Microsoft hasn't helped to mitigate this problem.
So, basically no different to DHCP on v4. And the mitigation is the same as it is in v4: layer 2 security via DHCPv6 Guard.
This is mentioned in the very guidelines that are the subject of the article you're replying to. The guidelines that aren't even five pages long.
This isn't even cliff notes for secure networking.
If the NSA needs the government's staff to get their shit together, this won't cut it.
The admins need step by step guidance to configure these changes on the actual systems they use. Clear intelligible steps with examples, preferably tailored to the platforms they have approved for use on secure networks. So if it's cisco gear, there should be a step by step guide to deploy and configure it to their guidelines, not just 7 pages of guidelines.
and a telephone number to call with questions.
Yes that's a lot of work, yes it would cost a few bucks, but we will waste orders of magnitudes more continuing to ignore the problems. We will also have to deal with the non-monetary damage that failures and breeches will cause.
Extensible headers are just about the simplest mechanisn to smuggle a data stream past inspection, so that's one that you have to kill if you come across it.
As for moving from IPv4 to IPV6, there are some Asian countries (Japan most notable) who have done that years ago. They have the expertise and experience, and have already made the mistakes we're only just about to make, so I suspect their network engineers will be making a pretty mint for a while..
I hope that they are actually planning out their networking domains properly so that they can actually leverage IPv6 address space without managing addresses on the devices but use IPv6 properly so that the hardware ID is part of the address and you're only segmenting the networks in the network address portion of the IPv6 scheme. Seen several large companies (one a network telco) screw up their initial layouts and to move forward they just started assigning any IPv6 addresses as needed to various devices, taking away the flexibility of the self assignment based upon the network that it's residing on. Giving themselves all of the overhead of managing addressing and networks from IPv4 into IPv6.
You still eat the cost at the DNS mapping layer, which is essential to any sane or normal IPv6 functioning. So tying how you issue addresses to a hardware ID raises a whole class of problems without really saving you much work. You would need to link to DNS anyway, and you can let the address server get it's entries from the DNS instead of the other way round, at which point there is not much savings to hardware IDs and less steps.
You also can't really trust the client to make sane or smart choices, so if you have to pin down how the clients get addresses anyway, why open the door to the client throwing a wrench into the mix? It's not like you can trust the client when it announces the hardware ID anyway, to the degree that it matters. Many mobile clients are randomizing them themselves for privacy, and a bad client could try spoofing.
This guidance is for secure networks that should have layers of security services, auditing, etc. Not a Starbucks public WiFi.
I find worrying that a seven-page NSA Guidance document - so only high-level guidance - published in 2023 references security documents prior to 2015 and the key NIST document "SP 800-119 Guidelines for the Secure Deployment of IPv6" was published in 2010 and no longer seems to be readily
available.
It's just outdated nonsense.
"The assigned IPv6 address incorporates media access control (MAC) address information from the network interface and may allow for host identification"
That's been untrue for both Windows and Linux hosts for years. (You still see it in some cheap devices such as $100 printers.)
"That's been untrue for both Windows and Linux hosts for years."
So that's all of the hosts and operating systems on the DOD/Gov secure networks then?
And of course they are all on the latest versions of those operating systems
And the NSA obviously recommends the blind trust in the individual systems and the operators thereof to not change them back of the defaults
And the government isn't logging that traffic at all, and wants to make it harder or impossible to correlate traffic to clients that randomize the hardware ID.
So recommending an easily deployed service like DHCPv6 that avoids a bunch of those problems and limitations is just crazy right?
Nonsense?
Yeah, it's nice to see the collected summary, but this needs to be one document out of a trove of deep dive guides on the actual details of implementation.
(as to the issue with that NIST doc disappearing, I think it got hugged to death)
https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-119.pdf
Don't worry tough, I suspect that the ACTUAL government can still get it from other places.
(and apologies if you are actually the government, your admins might of gotten exited, but it was loading fine a second ago for us pleebs outside)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
