DOD's Third Attempt To Implement IPv6 Isn't Going Well (zdnet.com) 136
The US Department of Defense is woefully behind on its plan to upgrade its IT infrastructure to support the newer IPv6 protocol, according to a government report published on Monday. From a report: This current effort is the third time the DOD attempts to upgrade its infrastructure to support IPv6 over in the past 17 years. The first two attempts took place in 2003 and 2010, respectively. The 2003 effort was abandoned with the DOD citing security risks and a lack of personnel trained in IPv6, while the second attempt was also abandoned, similarly on the grounds that IPv6 was not yet secure enough for the DOD's sensitive networks.
On Monday, the Government Accountability Office (GAO), the auditing agency of the US government, said that the DOD's third attempt isn't doing any better either. GAO officials said the DOD failed to follow four basic requirements that were set out by the White House Office of Management and Budget (OMB) in 2006. The four requirements were part of an OMB guideline sent to all federal agencies detailing the proper procedure for upgrading networks from IPv4 to IPv6. "For its current [third] initiative, DOD has not completed three of four longstanding OMB requirements," GAO auditors said in a report published on Monday.
On Monday, the Government Accountability Office (GAO), the auditing agency of the US government, said that the DOD's third attempt isn't doing any better either. GAO officials said the DOD failed to follow four basic requirements that were set out by the White House Office of Management and Budget (OMB) in 2006. The four requirements were part of an OMB guideline sent to all federal agencies detailing the proper procedure for upgrading networks from IPv4 to IPv6. "For its current [third] initiative, DOD has not completed three of four longstanding OMB requirements," GAO auditors said in a report published on Monday.
Just like most newer things. (Score:4, Insightful)
Re: (Score:3)
If you think IPv6 is more complex than IPv4 and the system of routing and services built up to manage them then you're not really paying much attention. Likewise the code for IPv6 is likely in many cases less complex as is typical when you're not dealing with 40 years of legacy.
Re: Just like most newer things. (Score:2)
Re:Just like most newer things. (Score:4, Insightful)
The problem is that IPv6 is different in behavior from IPv4 so it means that it's hard to re-train the people maintaining the infrastructure.
IPv6 has therefore come to be a solution in search of more problems than the need for a wider address space.
If it had only extended the address space but kept the overall perspective (even if it was deemed to not be ideal) of IPv4 then it would have been a lot easier to migrate. But now IPv6 has a huge number of new features added that requires new sets of understanding. One such thing is that it's seen as "dirty" to have NAT, something that most people know what it is and instead have randomization of addresses, which means that instead you have a huge new set of trouble to take care of. (How the heck do you capture malware traffic when you have address randomization?)
Re: Just like most newer things. (Score:5, Insightful)
Re: (Score:3)
And a big learning curve is why it fails.
Add to it that many ISPs are hesitant to implement it even if the effort for them is a lot less complicated than for the end users.
Re: (Score:2)
Re: (Score:3)
Re:Just like most newer things. (Score:4, Insightful)
Agreed, but that does not make IPv6 complex, less secure or inauditable.
Much of the "complexity" of IPv6 comes from depreciating the many additional truly complex things we bolted on to IPv4 to keep it functional. If all it did was take IPv6 and increase the address space then it would truly remain complex, as it would be yet another bandaid on the gangrenous wound of IPv4's original insufficiencies in the modern world.
One such thing is that it's seen as "dirty" to have NAT, something that most people know what it is and instead have randomization of addresses, which means that instead you have a huge new set of trouble to take care of. (How the heck do you capture malware traffic when you have address randomization?)
Well I'm not sure what you are concerned with there but I'm guessing it's a scenario that was come up with from a lack of information. Firstly NAT isn't "dirty", NAT is actively damaging to the end to end principles of a network. There are actual technical reasons to get rid of it, and these don't actually impact the likes of the DoD who sit on enough IP addresses to not need to NAT a large chunk of their infrastructure. But I digress...
IP addresses are just a number. Whether they are fixed or random is up to implementation. DHCP assigns them on a first come or a previous reservation basis. IPv6 doesn't change that, it merely changes the protocol with which it gets the addresses, and if you so insist you can actually use DHCP anyway though traditionally a host would use NDP to identify its address and then IRDP to announce itself to the router or assign them manually. One thing that you can do is since you now have the opportunity for a far larger address space you can actually arrange your internal network using prefixes and actually make it easier to audit where data is going. Everything else happens the same way it used to. Firewalls and network inspection. Having a different number doesn't change that. By "address randomization" do you mean a host gets a unique address every time they boot up? That's not the case by default, default IP assignments are infinite, also you can also use EUI-64 assignment meaning the IP address identifies the MAC address of the PC making assignment even less "random" than it was with IPv4.
Re: (Score:3, Interesting)
I tend to disagree here - by changing too much from what is familiar from IPv4 strategies where there are proven concepts even if they are formally bad is what's causing the inability to adopt IPv6.
Even if NAT is "damaging" the end to end concept it's not totally bad, sometimes you don't want to expose the "end to end" channel and there the NAT can serve as a gatekeeper (even if it can't catch everything). Many organizations and network strategies today depends heavily on NAT and when they now get told that
Re: (Score:3)
IP addresses are just a number. Whether they are fixed or random is up to implementation. DHCP assigns them on a first come or a previous reservation basis. IPv6 doesn't change that, it merely changes the protocol with which it gets the addresses, and if you so insist you can actually use DHCP anyway though traditionally a host would use NDP to identify its address and then IRDP to announce itself to the router or assign them manually.
This is the worst corner of IPv6 and you are holding it out as a nice clean solution.
Of course we are going to use DHCP, because we need to lock the address of sensitive systems so that we don't have to consult a dynamic database of host to IP address assignments. Refusing to allow DHCP to deliver the valid router addresses force us to wait for vendors to implement RA-guard in the edge switches, which wasn't really up to snuff till a couple of years ago (and likewise ND protection took a while.) No, we do
Re: (Score:2)
Can you explain your reasoning here. the Problem with IPv4 is the layers needed for NAT and routing problems, as a way to keep IP Address usages under control.
By allowing a larger number range, a lot of the problems are solved very well, with a simpler approach.
Re: (Score:2)
You're forgetting the complexity of changing all the firewalls they must have, upgrading apps to support IPv6, etc. It's not just flipping a switch or setting up a dhcpv6 server.
Re: (Score:2)
That is complexity of the project (fully in agreement) and not complexity of the system (what the OP was talking about).
Re: (Score:2)
NAT started as a way to ease IPv4 scarcity. Like most technologies its use transcended that and it is now commonly used as a building block in a lot of cloud hosting arrangements which have rather quirky, complicated routing requirements. In the simplest of cases, it (and the associated private IP addresses) are used to discriminate traffic to be routed through VPN tunnels from traffic to be routed by public Internet, sometimes both types of traffic between the same pair of endpoints. This can all be don
Re: (Score:2)
IPv6 is not less secure than IPv4. At the very least, just use a tunnel. IPv6 is not more complicated, in many ways it is simpler. The complexity lies with trying to continue supporting IPv4 infrastructures (NAT, old routers, etc).
I can understand if it's phrased as IPv6 security infrastructure is not as well understood than legacy IPv4 security infrastructures. That's just another way of saying "we're not ready yet". (but in some sense, a legacy security infrastructure might not necessarily be as secur
Re: (Score:3)
IPv6 is less secure than IPv4 on the managed corporate LAN due to the changes in the way network interfaces are assigned addresses, and a mandatory link-local address on top of that. Equipment has caught up to it now, but for over a decade you choices were extremely limited if not nonexistent if you were trying to find edge switches that could prevent IPv6 attacks such as spoofing RA packets.
Re: (Score:3)
At their core, the codebase of IPv6 and IPv4 are extremely similar. ARP is removed and unlike IPv4, IPv6 makes heavy use of multicast rather than broadcast for the purpose of neighbor discovery and router discovery. This makes the code substantially simpler, cleaner and actually more secure.
The issue however is that the vast majority of IPv4 security comes from NAT. The beauty of NAT is that nearly all sites on the Internet (homes, businesses, etc...) cannot al
It would have gone better (Score:2)
Re: (Score:2)
Yea it is too bad that we don't have technology where we can use say a pointing device to highlight a set of text, perhaps do an action that can save that text in RAM, and then retrieve that information from RAM, and place in in the input buffer.
I think I will call this technology Copy and Paste.
Re: (Score:2)
Why even risk mistakes? In my opinion, once data goes into a system it should rarely have to be hand-typed again.
Re: (Score:2)
If he's trying to get his machine connected to the internet then why doesn't he ask others to ping him by multicasting "ping6 ff02::1%eth0". If that works, he has connectivity. Or maybe you do have a case if a specific machine on his network is trying to talk: "ip neighbour show |grep 7334".
If either of those don't work then the machines can't talk to each other or are not on the same network and thus have no business pinging each other via IP address, and you should fix your own DNS problems first.
Re: It would have gone better (Score:2)
It's too bad there's no solution for mapping easily remembered names to IP addresses...
Re: (Score:2)
The problem is that whenever anyone at the DOD uses the term DNS they think it's a reference to the Division of Nuclear Safety, and the security people go nuts.
Re: (Score:2)
Re: (Score:2)
And I hear this argument, and it doesn't really hold that much water. Sure, you may know that your server is 10.28.111.3 and have it memorized but that's a trivial advantage. I've een using IPv6 at work for over a decade and these issues just don't come up. Ping by name (except the DoD names for the computers will be longer than the ipv6 address). Ping by "7334". Assign the key address to env vars. Use your hosts files for something other than ad blocking.
It would be even simpler of course if we only h
Re: (Score:2)
Two possible answers to that question:
a) "ip neighbour show |grep 7334" yep I see your machine on the network.
b) Dude why are you asking me to ping a machine not on our network, fix your DNS and give me a call when you lean to IPv6.
Re:It would have gone better (Score:5, Interesting)
That's why you grab for stuff like 2001:beef:feed:0000:0000:cafe:1337:cafe
Exactly. This has been my experience with ipv6 networks. Except a lot less dealing with public addresses. So all internal networks use the fd00::/8, which is basically the 10.0.0.0 network of ipv4 days. From there you just assign out your subnets, so the network would be broken like fd00:1 is webservers, fd00:2 is dns, dhcp, and so on. So if someone was having to ping a server, like hey hit dns-2. It's a ping6 to fd00:2::2. Or if someone was like hey try getting to Accounting (3) web vm 5, that's a ping6 to fd00:1::3:5.
As for, hey can you ping the router. The best thing about that is the router is always the same address on ipv6. ping6 ff02::2 is always the link local gateway address. So you don't have to even look up the ip config. Want to test if the machine can hit the nearest router? Just ping ff02::2. Want to know if you can contact the site's dchpv6 server? That's ff05::1:3, every time. And there's a scheme to all of this that makes sense. So you just have to learn it once and it literally applies to every single network you will ever work on in ipv6. And if you can script, it can make building up a listing of IP addresses that much easier because you just hit special addresses and ipv6 will give you back what the link-local or site local address is for the special class. So you ping6 ff02::2 and it'll tell you that your router is fd03::5:ab:1 or whatever. It will literally tell you.
Everything about ipv6, things like special classes and the higher order bits make it easier for you to manage your network, not harder. But you do have to learn the special classes. But you had to do that with ipv4 with things like 10.0.0.0/8, 100.64.0.0/10, 127.0.0.0/8, 169.254.0.0/16, 192.168.0.0/16, and 224.0.0.0/4. Not only that, you don't have special classes with ipv4, so your router could be 192.168.0.1 or if you're on a subnet it might very well be 192.168.0.64. You just have to look at what the system has the default gateway set to. On ipv6, it's always whatever ping6 ff02::2 tells you, that's what that special class means. The IPv6 stack will always translate ff02::2 to whatever you have your default gateway set to.
Re: (Score:3)
Of course, using addresses like fd00::1 is not how you are supposed to do it. You are supposed to randomly generate a /48 (e.g. fd5e:210:bea7::/48). The bad news is it makes your addresses 'ugly', the good news is that should you ever vpn into another ULA network, you are almost certainly going to be trouble-free with respect to conflicts.
Other than that, there are a ton of conveniences in IPv6 like you say and more.
The biggest frustrating factor is that DNS gets mucked with so much that it is hard for priv
Re: (Score:3)
This doesn't work on Ubuntu 18 ... so doesn't always work:
$ ping6 ff02::2
connect: Invalid argument
Re: (Score:3)
On Ubuntu and Unix like environments you need to add "-I" to your command to indicate interface. So the following command.
ping6 -I enp6s0 ff02::2
And you can use tab completion on the -I parameter so you need only type e, which is enough to indicate Ethernet, but you can double tab to get a list in case you have a ton of interfaces. So yeah you have an extra step but it's not that hard to overcome.
Re: (Score:2)
Naw, use a link local address to configure things or to talk to a disgruntled device. I really don't understand why people think we need to stick with IPv4 for the next thousand years.
Re: (Score:2)
Then someone should have nixed this in the bud back in the 80s when IPv6 was being designed and instead said "no more then 2 million computers, ever!" Problem solved! We already have more devices on the internet than IPv4 has addresses. It only works because of terrible ugly hacks like NAT.
These problems are already solved anyway. Many of these devices are ALREADY on IPv6. All your phones are IPv6, your IoT devices are IPv6 for the most part (maybe not consumer crap).
I've been doing IPv6 for a decade. N
Re: (Score:3)
When the only tools you have is a hammer every problem looks like a nail. There is practically no reason to ever ping a specific machine by its full IPv6 address even when debugging.
When debugging you check the router advertisement: ping6 fd00::1%eth0
If that works check NDP:
ip neighbour show
And if that works then the problem is not on your network card and you're successfully communicating two way with other machines on your network.
This isn't a human factors problem since any attempt to ping the machine in
Re: (Score:2)
Much better!
Here's what they should have done:
IPv4 /16
Cut off mainland China and Brazil and reallocate their blocks
Reallocate any other blocks larger than a
Stop trying to do "Internet of Things" shit without putting them behind some common gateway that needs just a single IP/port for outside access and has at least a snowball's chance in hell of being updated / secured / locked down
IP v6 - another sky that didn't fall (Score:2)
While I certainly agree that IPv6 is necessary, let's be honest that the strident claims that we were "running out" of IPv4 addresses were vastly overstated and histrionic.
Has part of the DoD's failures here been not just fundamental incompetence (of which there's plenty, I'm not gainsaying that), but a sense of urgency that was inflated compelling rush-decisions that really didn't have to be made in that context, and could have been a little more carefully contemplated?
Re:IP v6 - another sky that didn't fall (Score:5, Insightful)
let's be honest that the strident claims that we were "running out" of IPv4 addresses were vastly overstated and histrionic.
Not exactly. We developed technology to work around the problem. Consumer NAT, and Carrier Grade NAT. Without both of these (and even with the string of problems the cause) we would have had to switch to IPv6 by now.
Re: (Score:2)
The headlines that "we're running out of ipv4 addresses!!!!" were LEGION.
Nearly NONE of them suggested or even considered the fact that there were ALREADY technical work-arounds.
That there were work-arounds makes it clear that the histrionics were misplaced. Noah predicting the flood would have been a lot less powerful message if everyone already had plenty of boats.
Cry wolf enough, and people stop listening.
Re: (Score:3)
The headlines that "we're running out of ipv4 addresses!!!!" were LEGION.
We did run out of IPv4 addresses. If you were setting up a pan-European network in the late nineties you could go to RIPE and get /19s for each country. That pool is now exhausted, and you have to buy addresses at the market rate.
Nearly NONE of them suggested or even considered the fact that there were ALREADY technical work-arounds.
That there were work-arounds makes it clear that the histrionics were misplaced. Noah predicting the flood would have been a lot less powerful message if everyone already had plenty of boats.
Some of these boats, like CGNAT, might be a little leaky. Do you want to fix NAT problems by rebooting your home router, or by persuading some ISP to fix your connections (and a thousand other users) in their big box?
Cry wolf enough, and people stop listening.
It's not crying wolf when it actually happens [potaroo.net]. Let's see what hap
Re:IP v6 - another sky that didn't fall (Score:4, Insightful)
Nearly NONE of them suggested or even considered the fact that there were ALREADY technical work-arounds.
Yes they did, and the workarounds are horrific. Thanks to the work-arounds you now have every goddamn piece of software requiring a corporate middle man, some shitty cloud server, an UPNP to punch holes through routers just so you can get two damn machines to talk to each other. NAT is a horrible workaound. CG-NAT is fucking atrocious solution and severely limiting to your ability to actually make use of an internet connection you pay for.
The wolf is right there in the sheep pen. Simply because he hasn't eaten the sheep doesn't mean you don't have a huge frigging problem on your hands.
Re: (Score:2)
Thank you for saying it!
Running out of IPv4 space and being NATted is exactly why all this cloud-requiring BS started.
Re: (Score:2)
Re: IP v6 - another sky that didn't fall (Score:2)
We were running out. And we still are. But the industry as a whole has relieved pressure through IPv6 rollouts, address block sales, and an insane amount of NAT.
Re: (Score:2)
Has part of the DoD's failures here been not just fundamental incompetence
Maybe but it wasn't based on some sort of "rush". The DoD was asked to take inventory of every device that uses IPv4 and they couldn't produce the list. It's basically failed every time because they have no master inventory list of their devices, which is absolutely horrible record keeping. They may very well have to go back to the drawing board and remove the requirement to enumerate every device to ever actually complete the process.
Re: (Score:2)
We were running out, it was not a mistatement. However we found some detours to avoid driving off the cliff: an ugly hack called NAT, and putting all the smart phones on IPv6. So now we're driving parallel to the cliff but eventually we're going to have to cross that canyon.
Time to carefully contemplate is one thing, but what I see is plenty of organizations just dragging their feet for 20 years.
Re:IP v6 - another sky that didn't fall (Score:4, Insightful)
let's be honest that the strident claims that we were "running out" of IPv4 addresses were vastly overstated and histrionic.
They weren't -- but people who don't know any better (or who were just reading low-info articles) may have got the wrong idea.
We have run out of IPv4 addresses a number of times now. The problem with understanding this is twofold: 1. the address delegation system has several layers, from the IANA to the RIR to the LIRs, and 2. some people seemed to think that "running out of addresses" for some reason meant that their existing addresses were going to disappear.
The truth of the matter is that the IANA ran out of IPv4 blocks to assign in 2011. The Regional Internet Registries (who get their address block assignments from the IANA) ran out in 2011, 2012, 2014, and 2015 (with AFRINIC still having 12.13% of a /8 still available for allocations in Africa). The main authority, and 4/5th of the worlds RIRs are out of addresses, and have been since at least 2015. They have no more addresses to give.
LIRs still have address pools, so if you're an ISP you likely still have addresses you can give out to customers. But if you want to start a new business and setup a massive datacentre with several thousand addresses, you're either going to be forced to go through an ISP that still has available addresses, or you're SOL. Existing big players like Google, Microsoft, and Amazon very likely already have pools of extra addresses -- but new players are left out in the cold. There are no more addresses to be had.
That actually drives business towards the Googles, Amazons, and Microsofts of the world -- they have the addresses, and have become the new landowners. This has a negative impact on the Internet economy at large, as new entrants are at a huge disadvantage in the IPv4 space.
As well, running out never meant that existing addresses were going to go away. People and organizations that already have IPv4 addresses aren't going to feel the pinch -- it's emerging markets and new businesses that feel the pain. Not Joe American with a Comcast DOCSIS modem sitting by his desk.
So the sky has fallen -- but not everyone is impacted by it the same. Many people aren't impacted by it at all. Those who are impacted the most simply can't access the IPv4 internet to complain about it online. So what you really mean when you say "the sky didn't fall", what you really mean is "meh, it didn't impact me when the sky fell". But those are two different things, and just because you personally weren't impacted didn't mean it didn't happen.
The IANA have no IPv4 addresses. APNIC has no IPv4 addresses. RIPE has no IPv4 addresses. LACNIC has no IPv4 addresses. ARIN has no IPv4 addresses. AFRINIC has ~12% of a /8. LIRs might have some smaller blocks still available (particularly for their own customers use) -- but if you're a new organization that needs a sizeable allocation in IPv4, you're SOL. Virtually every address has been assigned. The sky fell, there is nothing more to give.
Yaz
Re: (Score:2)
Given that it was the DoD that came up w/ IPv4 and initially assigned distributions before having one guy Jon Postel assign subnets to everyone, one could assume that if any organization was guaranteed all the addresses it would ever need, that would be the DoD
That said, long term, it is important for everyone to move to IPv6, and maybe test it out completely w/ newer protocols like SCP and the like. And for those who focus on security, all security won't be at layer 3 anyway - it's worth ensuring the se
To be fair... (Score:3)
It's always easier to tell other people how to do their business, which is what the OMB is doing here.
To be fair, taking an inventory of all IPv4 devices is pretty pointless. Somewhere, in the bowels of hundreds of warehouses, there are probably millions of devices that can't deal with IPv6. Most of which are of little to no importance. There's not much point to making a list of them - it's not going to change anything.
Seems to me the simplest approach is like ripping off a band-aid: just do it. Give all the internal departments a bare minimum of warning, so they can prepare as best as they can. Then change the core services to IPv6-only and see what breaks. Fix things as you find them. In a few months, everything critical will be either fixed or worked around - and you'll know what non-critical things still need done.
Not elegant, not pretty, but a lot more efficient than another 20 years of dawdling...
Re: (Score:2)
It is also why our homes seemed to have every room wired with a plugs, that can provide a potentially lethal amperage and voltage. While most of our devices (cell phones, laptops, LED lights) now use much lower power, in safer DC.
We could have say USB plugs in our home for better energy usage. But we still have 15+ amp AC and we have an AC to DC converter for most things we plug in.
Re: (Score:2)
I developed a phased approach for a federal agency some 6 year ago... In order to cope with the challenges of taking inventories and re-architecting the entire network, it can be broken up into smaller more manageable projects. No massive inventory project required. If I can recall correctly, it went something like this:
End-user client workstations in major corporations are largely Windows with some MacOS). Both of these support dual-stack TCP/IP implementations. Start by making the routers on your cl
IPv6 is a failure (Score:5, Interesting)
We should have abandoned it years ago.
There was a proposal to add two more octets to IPv4. We'd have been switched in record time.
192.168.100.1 to 222.204.192.168.100.1
vs
192.168.100.1 to 2001:0db8:85a3:0000:0000:8a2e:0370:7334
and it would have been much easier for backwards compatability.
Agreed (Score:4, Insightful)
128 bits was an absolutely absurd decision. Its approx 10^20 times the number of grains of sand on earth! Even if you divide it up into various networks and topologies of hopeless inefficiency and Iot is used around the entire solar system you'd never come close to using all that space. There's future proofing and then there's just being bloody idiotic.
Also its too complex to set up and to administer a network. Sure, a lot of it is supposed to be automated but when that fails manually troubleshooting is a royal PITA. The fact thats its been around for over 20 years and yet still people don't want to have to use it unless pushed should really have told the IETF by now that its not fit for purpose. But I doubt they'll listen.
Its time to abandon it and come up with something simpler
Re: (Score:2)
Seems incredibly smart to me. Look how long it's taken and we're still not fully on IPv6. Going through this a third time would be a nightmare. The number of devices is only increasing. I have 64 devices on my home network right now. if wearables, smart appliances and other smart things take off, consumers alone will be using 100+ devices at home.
Many cloud providers didn't offer IPv6 for a long time. Even now, it doesn't work with all AWS AMIs, usually due to platform limits. Most providers won't let you
Re: (Score:2)
And it's easy to use really. You can't memorize all the addresses but that's a trivial problem.
IPv6 addresses *should* be using your MAC address as the lower 64 bits. So if you're not getting a static IP address then maybe you're getting a different prefix each time? Or maybe it's ISPs just being dumb about this and not really wanting to move away from NAT or keeping the same DHCP style. Maybe once IPv6 is more common then this changes? After all, we used to not have NAT and then it was suddenly everyw
Re: (Score:3)
Re: (Score:2)
The same problem exists for everyone with a static IP also. But there is potentially a problem in many small ways that IPv6 is out of date in relation to modern privacy concerns. However, IPv4 is not any better anyway and has many many more drawbacks. The argument then should not be IPv6 vs IPv4, but those standards versus something else (IPv8, not-IP, etc).
But privacy can still be had; tunnel your packets, use a different IP address for each web site you visit, etc.
Re: (Score:2)
Honest question, are you suggesting IPv6 does not have the concept of NAT? Does that mean my computers attached to my router (they all have both IPv4 and IPv6 enabled) are directly addressable by the outside? Is this the security risk people have been talking about here? I assumed the router would have an IPv6 address and it would otherwise work the same as with IPv4, where I would have to set up special rules to have a port direct to a particular computer/port.
I see so many talking about security, but I
Re: (Score:2)
IPv6 does not have NAT; however, if you have a router that does IPv4 w/ NAT and IPv6 and it has a "firewall" that controls which traffic is permitted through (in either direction) based on rules, those rules continue to apply for IPv6 just like the do for IPv4. NAT and Firewall are two different things. NAT has nothing to do with security. Firewall is what makes things secure.
NAT just allows your internal network numbers to be addresses that are not unique across the global internet. The NAT translates betw
Re: (Score:2)
First of all, thank you! I do appreciate your taking the time to answer my question.
It makes sense, and I've still been operating on the premise that NAT would reliably protect my machines because they are not directly addressable. If an attacker were to throw my home IP address out, they would hit my router, not my machine.
If nothing else the discussion on this topic will prompt me to update my understanding of my own network configuration (still operating on what I learned poking around when I was in hi
Re: (Score:2)
And it's easy to use really. You can't memorize all the addresses but that's a trivial problem.
IPv6 addresses *should* be using your MAC address as the lower 64 bits. So if you're not getting a static IP address then maybe you're getting a different prefix each time? Or maybe it's ISPs just being dumb about this and not really wanting to move away from NAT or keeping the same DHCP style. Maybe once IPv6 is more common then this changes? After all, we used to not have NAT and then it was suddenly everywhere.
That's a bad solution, b'cos it then tells any attacking system what your Layer 2 address is. There is a system called EUI-64 that uses that, and OSs that use that, such as BSD, use it in link-local addresses fe80::/10. The best way to handle it is thru DHCP6, where one should be able to define the addresses the host can take
My fault. BIOS, FAT, etc (Score:5, Interesting)
I have to agree, 64 bits would have been enough. I'm one who argued for 128 during the IETF discussions.
At the time, we were having problems with the 2GB limits to drive and memory sizes and other sizes in Windows, because someone had thought 32 bits would be plenty. I was running a large RAID array and the 2TB limit, again because of 32-bit fields. At the same time, the bit size of IP addresses was a big problem (we didn't have carrier-grade NAT at the time).
BIOS too had problems from not having enough bits available.
My thinking at the time was that people had thought "16 bits is enough" and that caused problems. They thought 32 bits was enough, then it wasn't. Some of my IETF peers thought 64 bits would be enough. I had seen the "x bits will be enough" story enough times to remember how that ends up. It always turns out in the future you wish you had twice as many bits.
So I pushed for more bits, for making sure we don't run into the same old problem of not enough bits AGAIN.
Now, CPUs are 64-bit. 64 bit numbers are standard I databases, etc. 64-bit numbers are east to use. 128-bit are not. Had I to do it over again, I would vote for 64-bit instead of 128. Actually what I would propose would be something like this:
Consider if you're in the US, when you give out your phone number you don't have to include the country code. It's assumed. I'd follow a similar pattern.
IANA will only assign 64-bit addresses starting with bits 01 until we run out, maybe 70 years from now.
All addresses with 01 in the 64-63 bit positions (all of the addresses we actually use) are defined to technically be 64 zeroes followed by the 64-bit address. The first 64 bits, all zeroes, are assumed. You don't need to write them.
If, 50-100 years from now, we run out of "64 bit" addresses, we have plenty more available by starting to use the other 64 bits which had been assumed to be all zeroes.
A 128-bit compatible device must treat any 64-bit address as 64 zeroes followed by the 64-bit address.
Devices which are not 128-bit compatible should error appropriately when they get an incompatible address, one that doesn't have the 01 flag bits.
That way, 40-50 years from now, if necessary people could start making 128-bit compatible devices and code, according to an already established spec, while maintaining full backward compatibility with 64 bit addresses. Simply by treating 64-bit addresses as 64 zeroes followed by whatever the address is.
Re: My fault. BIOS, FAT, etc (Score:2)
In other words you knee jerked instead of thinking. If that's how world networking standards are though up god help us.
Re: (Score:2)
"Now, CPUs are 64-bit. 64 bit numbers are standard I databases, etc. 64-bit numbers are east to use. 128-bit are not."
Sure they are. Many processors have 128 bit data types. And 16 bit computers were able to handle 32 bit addresses without undue effort.
Re: (Score:2)
> Many processors have 128 bit data types
Some do. Just not Intel, AMD, or ARM. :)
To the best of my knowledge, Intel has a SIMD vector of four 32-bit numbers. So you can hack around it.
Microsoft SQL is bitch with 128-bit numbers.
Re: (Score:2)
ISTR that both Intel and AMD have 128 bit data types in their multimedia extensions.
Re: (Score:2)
It's my understanding that SSE provided a 128-bit register which was accessible as four 32-bit numbers, but not usable as a 128-bit number because the rest of the CPU couldn't do anything with 128 bits anyway.
Later versions of SSE run on 64-bit processors so the register can now be addressed as:
2 64-bit floating points (double precision)
2 64-bit integers
4 32-bit floating points (single-precision)
4 32-bit integers
8 16-bit integers
16 8-bit characters (bytes)
No 128-bit number, so you can't directly increment a
Re: (Score:3)
So I pushed for more bits, for making sure we don't run into the same old problem of not enough bits AGAIN.
128 bits was the right decision. 64 bits would have been a mistake.
128 bits gives enough bits to simplify and optimize routing decisions, while also leaving enough bits left over for address randomization, fixed service addresses, etc., to enable elimination of DHCP. I don't think we'd be able to achieve all of that with only 64 bits... not and leave enough address space for the inevitable growth.
Re: (Score:2)
> IPv6 works, where all the globally relevant information is in the first 64 bits and all the locally relevant information is in the last 64 bits.
No, we could have done pretty much exactly the same things, with fewer bit for each purpose. Do you REALLY need more than 4 billion IPs in your network? Really? 32 bits is just about enough for the entire planet, but it's not enough for your house?
Re: (Score:2)
> Cramming everything we do now into the lower 64 bits is basically calling for a new protocol. Not a single device on the internet will work with that.
I think you missed the "Had I to do it over again, I would vote for 64-bit instead of 128". If I could go back to 1997, I would propose that we set the topmost 64 bit to zeros and actually type in / use 64 bits for the next several decades. The same way you can dial a phone number with just 7 digits or 10 digits - the country code "1" assumed. (If you a
Re: (Score:2)
One thing done in cryptography is if you have a cipher for which 512 bits is enough, the spec defines it for 512, 1024, and 2048 bits. So you define it to allow for four times as many bits as "enough", the spec allows for significantly bigger numbers than you actually use for the first several years.*
Currently, I'm thinking a somewhat similar approach, a "best of both worlds" would have been good - work with 64-bit numbers now, knowing that this address:
6793 a7d9 e990 f7629
Really means:
0000 0000 0000 0000
Forgot the footnote (Score:2)
I wrote "the spec allows for significantly bigger numbers than you actually use for the first several years.*", then forgot the footnote.
* Unless you're designing Wireguard, in which case they hardcoded all of the parameters in a way that it's not clear how they could ever be be updated, nearly guaranteeing that the security of Wireguard will be broken in a few years and there will be no easy way to fix it.
Re: (Score:2)
128 bits was an absolutely absurd decision. Its approx 10^20 times the number of grains of sand on earth!
Nope. It was a technical decision designed to optimise and more efficiently route messages around the world. The number of addresses have nothing to do with future proofing to prevent running out. They have to do with BGP routes not limiting the speed of the internet due to insanely large routing tables.
Also its too complex to set up and to administer a network.
It is literally automatic. There's less you need to do to setup and administer than an IPv4 network. Just because you need to RTFM of a few new commands to see the inner workings of what's going on doesn't m
Re: (Score:2)
Yes I'm sure the multi billions of dollars spent on network infrastructure that doesn't support it will just magically be replaced overnight. In other news the fact that you still have a coal fired power station in your country is a sign that renewable energy isn't fit for purpose right? Or the fact that your old TV still works is a sign that 4K isn't fit for purpose.
Here I was clapping at this and cheering on your analogies...
I don't think I've ever seen a truly more stupid sentence put together than what you just wrote.
And then I lost all respect for you.
Re: (Score:2)
"Nope. It was a technical decision designed to optimise and more efficiently route messages around the world. The number of addresses have nothing to do with future proofing to prevent running out. They have to do with BGP routes not limiting the speed of the internet due to insanely large routing tables."
LOL, of course it was, yes, was the reason :)
"Yes I'm sure the multi billions of dollars spent on network infrastructure that doesn't support it will just magically be replaced overnight"
Do you understand
Structure erodes the address length (Score:2)
128 bits looks too much - until one starts bunching it together into words, and then building more structure into it. Like deciding whether to assign organizations /64, /48, /32 address ranges and within that, encoding what each range means. Like if an organization gets a /48, and decides to use the subnet word to have the first nybble mean location, second one mean building, third mean office and fourth mean room, that quickly limits it to 16 of each kind.
Speaking of which, what was ridiculous was fixi
Re: (Score:2)
In reality, any change from a 32 bit address would have been equally challenging, because a great deal of the transition headache was surrounding all the code that hard baked IPv4 into the code design.
Sure, the sheer length driving the hexadecimal address with colons is intimidating (and mucked up URI a bit by using colons) had some acceptance challenges, but practically speaking the challenges were far beyond that specific detail and the need for IPv6 was less urgent so people didn't work as hard on it.
The
Re: (Score:2)
Re: (Score:2)
All I know is that whenI tried to roll out IPv6 on my network I discovered I still had to support IPv4 for various things and services. I'm behind a NAT, so I have scads of available IPv4 addresses, so the big selling point of IPv6 isn't a factor.
Tell you what, IETF. Make a new email standard that only works on IPv6 that doesn't require a hojillion AV/spam scanners, Stupid SMTP Tricks or kowtowing to the big email providers (Google, Microsoft, and God help us AOL and Yahoo) and I'll jump on that wagon. Make
Re: (Score:2)
192.168.100.1 to 222.204.192.168.100.1
So that solves one problem, what about the rest? IPv6 has an insanely large address space to facilitate optimal routing. Maybe you should read up on how routing works on the internet to realise IPv4 and the way it was designed creates a very real problem for routing tables because of how addresses are being divided up.
Re: (Score:2)
Re: (Score:2)
There was a proposal to add two more octets to IPv4. We'd have been switched in record time.
No, you still would have required exactly the same amount of effort as deploying IPv6, with every router, modem, and computer needing to be redesigned and/or updated, except that in the end you'd have significantly worse routability. You do remember that packets sent to addresses have to be routed, right?
The IPv4 global routing tables are already a mess. Adding a few more octets without considering their impact on routing tables would have killed the internet, which is why it's good that people such as yo
IPv6 would have been adopted earlier (Score:4, Interesting)
Re: IPv6 would have been adopted earlier (Score:2)
What is there to understand? For the vast majority of network operators, it makes no difference.
Re: (Score:2)
It makes a difference when you suddenly have to consider to not administrate your private set of addresses internally but suffer from a huge number of added "features" to IPv6 that intends to "solve" problems with IPv4.
Network security is crap (Score:3)
Stop relying on IP addresses and private networks for security. It's an outmoded concept. The DMZ doesn't mean anything anymore. Every access must be authenticated, regardless of the IP address.
Re: (Score:3)
IPv6 is hard to sell as an "upgrade" (Score:3)
Those who are properly connected via IPv4 right now have no obvious incentive to invest money just to allow others to have more static, non-NATed IP addresses at their disposal.
. In reality, for the vast majority of current Internet users, this "upgrade" just downgrades their privacy / trackability and does not gain them anything.
If there was a sizeable, significant amount of relevant Internet peers with whom people would like to communicate directly, but could do so only via IPv6, that could be an incentive. But IPv4 users are not currently experiencing this as their problem.
No added value for IPv6 in most cases (Score:2)
Nobody is really interested in switching. A user could configure IPv6 in addition IPv4. But why bother? - There are no sites that are IPv6 only (and plenty which are IPv4 only - just check DNS entries). So IPv4 is always the first choice.
A sysadmin could configure IPv6 but again - why bother? Users are going to be unhappy if only IPv6 is configured (because a lot of stuff is available only through IPv4). So both IPv4 and IPv6 would have to be configured and maintained. That's at least double work, double
Re: (Score:3)
A user could configure IPv6 in addition IPv4. But why bother?
This is the short-sighted "we've got ours, fuck you" attitude. People who already have all the IPv4 addresses they could possibly need don't care about IPv4 exhaustion. They have theirs. It still works, and will continue to work into the future.
It's the people who can't get addresses that are impacted. The fact that investors likely won't touch new businesses proposing starting up major datacentres using IPv4. And all of those still developing countries that can't get address blocks to grow their Inter
IPv6 -- not secure? (Score:3)
... on the grounds that IPv6 was not yet secure enough for the DOD's sensitive networks.
I think only someone who doesn't understand anything about network security could write or say something like this.
I have a collection of servers and VMs running on them at a co-hosting facility. It turns out that the vendor provides excellent IPv6 support and guess what -- the much hated Comcast/Xfinity also provides excellent IPv6 support. And my $39 Microtik router has everything it needs to use it.
So I use IPv6 from home to all my servers/VMs and don't have to sweat allocating IPv4 addresses from the block of 16 the vendor gave me. Many of the OSes now don't have public IPv4 addresses at all.
Result: Those systems never get attacked or probed or scanned. The IPv4 address get the usual attacks constantly. But there is no way to scan for systems in a 64-bit address space and most bots don't even try, any more than they try to look for SSH on anything other than the standard port.
If they somehow learned the DNS AAAA records I use for them then I would expect attacks but they would be no more successful than the ones on the IPv4 systems I have.
IPv6 is no more or less "secure" than IPv4 but contrary to popular belief it is a lot simpler to use and operate. Time I would have to waste on IPv4 address allocation and NAT setup and setup tunnels that I don't need with IPv6 I could use to work on real security issues.
Re:IPv6 -- not secure? (Score:5, Interesting)
I think only someone who doesn't understand anything about network security could write or say something like this.
Only someone who doesn't understand the scale and scope of what's going on could write or say something like this.
We're not talking about small, medium, or even large-scale when we're talking about the DoD. We're talking about enormous. The sheer number of switches, routers, firewalls, servers, printers, random devices, and *applications* that need to be vetted, tweaked, re-configured, tested, debugged, and so forth is mind boggling. Further, DoD security classifications make messing with this stuff even more difficult, as a single screw up could end up worsening security instead of improving it. Much of this stuff is poorly documented, having been implemented piecemeal over decades with no master plan on how it should all interoperate. And changing over to IPv6 would have to happen in a way that doesn't disturb functionality while it's ongoing, something that is nigh impossible.
A good analogy might be why NASA used 1970's-era computers on the Space Shuttle long after better, faster, cheaper computers were available: the older stuff worked, was well understood, and had been thoroughly tested to the point where almost every possible failure mode was accounted for. Newer computers would've thrown all that onto the trash heap for...what, exactly? Faster processing? Not needed since the existing computers, though ancient, did everything the Shuttle required them to do.
So it is with IPv4 vs. IPv6. IPv4, while "ancient" in comparison to IPv6, works, is well understood, and has been tested and secured to the point that the DoD is at least minimally satisfied with its performance. It does what it needs to do as far as their needs are concerned. They have thousands of people who understand it, are familiar with its weaknesses and know how to mitigate them. Not so with IPv6. It's the case of perfect (IPv6) being the enemy of good enough (IPv4).
Re: (Score:2)
We're not talking about small, medium, or even large-scale when we're talking about the DoD. We're talking about enormous.
Apparently you seem to believe that the network has to be all IPv4 or all IPV6. So the plan is that everyone leaves on Friday with every computer having its decade-old IPV4 and come in on Monday and everything is switched over to IPv6. Well I guess I understand why you would be so confused.
No matter what size your network and how many systems you have under management the methodology is the same. Start with one sub group. It could be defined by a specific application or maybe a group of general pur
Profoundly disappointed in IPv6 (Score:3, Interesting)
In 2014, I bought an IPv6 book. I was doing networking customer support and thought I should get up to speed on it. It may have been that I had just a horrible book on the topic.
The first chapter of the book and most of the second was 100% about how big 2^128 is.
Then, chapter by chapter, feature by feature, the book would introduce a feature and tell all about how great and wonderful it was and then admit that, "well.... it doesn't really work because of X, Y, Z problems". And very often the remedy was to fall back to IPv4 concepts.
I stopped reading about 75% through the book and concluded that it (much like IPv4) wasn't really designed by anyone with any real competency. None of the glaring problems with IPv4 that I've been concerned about were even addressed. I can see, maybe, not being aware of potential problems when IPv4 was designed could be just lack of foresight but by the time IPv6 was designed, they knew full well what the security and performance issues were and I didn't really see any real attempts to address them.
If our enemies attack, will this help us fight? (Score:2)
Why are we experimenting with a large organization tasked with defeating our enemies?
Project lead might be paid T&M =) (Score:2)
I mean, I smiled as I read through the summary. I almost wanted to just post a one-liner to the effect of, "My 13 y/o son isn't doing much constructive these days, his fees are pretty moderate, he might be able to help you out". =)
In seriousness, I can't imagine the scale of a project like this. I assume in the States DoD collectively means the Army, Navy, Air Force etc. That would probably not only mean every server, workstation and mobile device; but also every warship etc. I've long forgotten the spe
"security risks/lack of trained personnel..." (Score:2)
Somehow, I believe that these two things are most likely one and the same.
I cannot see any possible security issues with IPv6 that v4 would not have also had that could not be addressed by someone who was properly trained for IPv6.
So in the end, the real reason it hasn't worked well before is because they are too cheap to make it work right.
Re: (Score:2)
Re: (Score:2)
Name one.
You are describing a catch 22, where you say you can't migrate to what might otherwise be an objectively superior system because it doesn't have enough of a track record to justify that alleged superiority, and claim it doesn't have enough of a track record to justify its superiority be
Re: (Score:2)
I hadn't heard this before. I thought the broadcasting really had more to do with hosts on the network being aware of other hosts, the replacement to ARP. I almost combined two thoughts you mentioned into one. It leaks information, and it's constantly broadcasting. Is it the mapping broadcast that you're concerned about leaking information?
I'm not an expert on the topic, I just went and referenced differences between v4 and v6 after reading some of these comments to try and gain some perspective. I'm l
Re: (Score:2)